Detecting worker allocation failure

[annevk]

In https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039 and more prominently in https://bugzilla.mozilla.org/show_bug.cgi?id=1052398 @lukewagner and @lars-t-hansen discuss problems with Worker objects getting created but their corresponding workers not getting allocated.

I'm curious to hear what @kinu, @sof, @travisleithead, @hober, and others think of that. Would it be acceptable to make new Worker() throw, should we have a second parameter to opt into that behavior, expose state on Worker objects, or something else altogether?

[zcorpan]

Previous discussion
https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Sep/0412.html
https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Sep/0414.html
https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Dec/0300.html
https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Dec/0304.html
https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Dec/0322.html

[zcorpan]

Would it make sense to opt-in to get a Promise, where both failed-to-load and quota-exceeded reject the promise?

[zcorpan]

(Not necessarily using the constructor, since constructors are expected to return an instance, but e.g. Worker.create(...) or so.)

[duanyao]

I think the root problem is the fact that running workers can't be swapped in/out -- by "swap out" I mean kill (or detach it from) its native thread, or even release its memory. If they could, a UA could select one to swap out and let the newly created one have a chance to run, if the quota is exceeded.

However, saving and restoring a worker's state (JS context) seems hard to implement for UA. So I suggest that UA just throw away a worker's state during swapout, and re-run its entry script during swapin. Of cause this may break existing codes, so I suggest to add an opt-in parameter swappable:

var swappableWorker = new Worker(scriptUrl, { swappable: true });

UA would only swap out swappable workers, so authors who want to create large amount of workers should make them swappable. UA could have two separate limits: "max non-swappable workers per-domain" and "max concurrent swappable workers per-domain", so that non-swappable workers can't block swappable ones. There is no hard limit on how many swappable workers can be alive at a same time.

It may be also useful to fire a savestate event to a worker that is about to be swapped out, so that it can save/restore state by itself.

UA should schedule swappable workers fairly, and also reduce interuption. For example, it is better to swap out an inactive worker than a worker that is doing computation or has pending XHRs.

If messages are posted to a swapped-out worker, UA should queue up them, and try to swap the worker in, and then let the worker process them.

[lars-t-hansen]

Swapping might be useful for some cases, but for the use case that started this thread - high performance computing where a worker acts as a thread, and where a worker can go to sleep synchronously waiting for a wakeup from another thread - it will not be appropriate. Here, it is much more important that the program have knowledge of the number of threads available to it, so that it can do its own resource scheduling with that information. Additionally, the thread will not normally return to its event loop so that it can be swapped out. Also, being swapped back in means having to restore state, which is going to require coordination with other threads since some of the state is stored there (shared memory objects).

In that case, some means of detecting that a worker failed to be allocated to an actual independent thread is required.

So not to shoot down the idea, which could work, but we need something else here.

[wanderview]

FWIW, the "swappable" concept is similar to what service workers do. The browser is free to kill the worker thread even though there is a ServiceWorker DOM object alive. The thread is restarted on demand, etc.

It comes with a big caveat for devs not to rely on global state, though.

[duanyao]

(copy of https://bugzilla.mozilla.org/show_bug.cgi?id=1052398#c34)

Well, for non-swappable workers, I aggree that UA should expose the number of available non-swappable thread and throw on failure of creating a thread immeditely. However, without swap, this may severely limit the number of workers that can be created.

Current spec allow UA to kill any worker at any time, this is even harsher than swapping, and for shared memory case may cause deadlock/data corruption too. Do we want to forbid this behavior (https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039)? I suggest take workers that share memory as a whole (like a process), and UA should kill/swap out all or none of them at a time.

For a worker that runs a tight loop, I think the UA may set a flag saveStateFlag of the worker to true when the UA want to swap it out; the worker should check the flag in the loop and save state, flip the flag, and continue. Is this OK?

---

@wanderview Yes, much like ServiceWorker.
To help authors to save/restore state, I think Web Worker may provide a set of APIs:

// Save state of a worker. `data` is "structured cloned" and hold by the UA 
// (not necessarily saved to disk for performance). 
// You can also transfer the ownership of large objects to avoid overhead.
void saveSate(any data, optional sequence<Transferable> transfer);

// Get saved state during last swapout
any getSavedState();

// Request the UA to swap this worker out immediately. If you transfered 
// objects when calling saveSate(), there is no point to continue running, of cause.
void suspend();

[lars-t-hansen]

Copy of my response on that bug:

(In reply to Duan Yao from comment #34)

Well, for non-swappable workers, I aggree that UA should expose the number
of available non-swappable thread and throw on failure of creating a thread
immeditely. However, without swap, this may severely limit the number of
workers that can be created.

Definitely. But for the use case at hand that is considered an acceptable cost.

Current spec allow UA to kill any worker at any time, this is even harsher
than swapping, and for shared memory case may cause deadlock/data corruption
too. Do we want to forbid this behavior
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039)?

As I've argued on that bug, I think that the Workers spec needs some kind of wording to allow workers to be killed, but it needs to define clearly the circumstances under which that may happen. The current wording is useless even for existing use cases, as there's no way to trust that a worker will ever do what it's supposed to do, even under the most benign conditions. That might make sense if the worker were a remote entity but not when it's running on the local computer, and has a means of reporting execution errors (as it does) but not to report anything when it abruptly terminates because of action by the UA.

I suggest take
workers that share memory as a whole (like a process), and UA should
kill/swap out all or none of them at a time.

It's possible that that could work, though not if the workers would have to cooperate in the swapping, as I think you're suggesting. A single uncooperating worker would prevent the group from being swapped out.

For a worker that runs a tight loop, I think the UA may set a flag
saveStateFlag of the worker to true when the UA want to swap it out; the
worker should check the flag in the loop and save state, flip the flag, and
continue. Is this OK?

Probably not, if it's not possible to opt out of swapping.

As Jukka and I both pointed out, "restoring state" is sometimes extremely complicated or in practice impossible. Swapping would have to be something to opt in to.

[duanyao]

(copy of https://bugzilla.mozilla.org/show_bug.cgi?id=1052398#c36)

Swapping would have to be something to opt in to.

This was exactly what I proposed :).

As Jukka and I both pointed out, "restoring state" is sometimes extremely complicated or in practice impossible.

Sometimes, yes. But in practice, all native mobile apps may be asked to save sate by OS and then killed on low memory condition, and later may be resarted and restored if user switch to it again. Even if an (web) app don't want to bother with "restoring state", it still have to deal with forced close/ crash conditions, and make its state consistent if that happend.

For some use cases we want unlimited number of workers. For example, zip.js (https://github.com/gildas-lormeau/zip.js) backs each opened zip file with a worker for deflating/inflating. It is frustrating that the number of simultaneously opened zip file is so limited, and affected by other usage of worker in a same domain. Making worker swappable is not trival but definitely doable in zip.js. Additionally, we can even back each opened zip file with multiple workers to take advantage of multi-core CPUs, without worrying about exhausting worker quota quickly.

Sure, a group of workers sharing memory must cooperate to be swappable. You have to make sure there is no "uncooperating worker" in this group. But you already have to make them cooperate to achieve memory safety, right?

Yes, I think UA should inform a worker and the holder of the worker that the worker will be killed (like SIGTERM or something?).

[annevk]

@duanyao please open a new issue for the swappable idea. It seems different enough (and more complicated too) for its own thread.

[annevk]

This is #851 now.