Consider a DedicatedWorker and SharedWorker closed getter

[wanderview]

Currently there are a few ways you can end up with a "dead" worker object:

1. The script failed to load
2. The script failed to evaluate
3. Tried to attached to a SharedWorker with a different isSecureContext value
4. Called terminate() on a dedicated worker

AFAICT there is no way to determine if a worker is in this closed state. You can send a postMessage() and test to see if it echos back, but that is not great.

Should we add a synchronous getter to detect if a Worker or SharedWorker is "dead" or "closed"?

I don't have a particular use case in mind. This just seemed like a hole in the API to me.

[annevk]

Is there developer need for this? Haven't seen a request for this thus far.

[wanderview]

Is there developer need for this? Haven't seen a request for this thus far.

No. As I wrote in the last paragraph of the original post, it just seems like a hole in the API to me. I don't have a specific use case for it.

[annevk]

I think the other problem with this proposal is that you don't have an event loop to do something with the changed state of this flag. We'd need to actually define destruction in more detail.

[asutherland]

For SharedWorker implementations that are (potentially) cross-process, dead workers can also result from the loss of the process hosting the SharedWorker. (At least under a model where even if there is at most one origin per process, there may still be multiple processes per origin. If there's only ever one process per origin, it's not a problem, but Gecko may have multiple process per origin even after its "fission" project.)