Firefox issues vis-a-vis shared memory spec

[lars-t-hansen]

Two issues I'm aware of so far, there might be more:

• When a worker is created, it is necessary for the creating agent to return to its event loop before the worker is actually created. If the creating agent forks off a worker and then waits on a location that the worker is supposed to update without first returning to its event loop it will wait forever. This is known to be a problem if the creating agent is the main thread, but Firefox allows nested workers and I assume (for now) that it is a problem even if the creating agent is a worker.
• There is a limit per domain on the number of worker threads. By default this is 20, it can be changed in a preference. A program that tries to create more workers than that will be led to believe that the creation succeeded, but in fact the new worker will not have a thread backing it. Programs can deadlock because of this. It is particularly pernicious because the limit is per domain and not per tab; having two tabs open from the same domain running the same program will halve the number of workers available to each, etc.

[lars-t-hansen]

The "return to event loop" problem is probably not allowed by the current WHATWG spec, but (so far) I have not found enough rigor in that spec to say for sure. The spec for creating a worker says (10.2.4 Processing Model) to fork off a worker and then run it ("Create a separate parallel execution environment (i.e. a separate thread or process or equivalent construct), and run the rest of these steps in that context."). This implies fairly strongly ("parallel", "thread or process") that immediate and true concurrency are required.

The issue of not creating the worker it until the creating agent returns to the event loop is observable to a remote server (XHR from the worker) or to the user (lack of output in console) and of course using shared memory (starvation / deadlock when the worker does not update shared memory or wake a waiting agent).

[lars-t-hansen]

The spec language quoted in the previous comment actually also prohibits the second Firefox issue. Both are issues regarding the timing of worker creation. But the first issue has a simple workaround (return to the event loop) where the second has only a complicated workaround (create a worker, return to the event loop, wait for a message from that worker that it is running, and if not, you know you're past your limit).

[lars-t-hansen]

Bug filed against the WHATWG spec here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29039

[lars-t-hansen]

One Mozilla bug with plenty of discussion: Bug 1052398, Web workers past the first twenty will silently fail to launch

[lars-t-hansen]

With the closing of Issue #36, Firefox no longer allows blocking on the main thread, neutralizing the first of the issues tracked here. (The per-domain limit is still a problem.)

[lars-t-hansen]

One idea that won't work but that has been considered (this a according to a conversation I had with Jonas Sicking) as a replacement for the current per-domain limit is a browser-wide thread pool where workers are multiplexed onto threads from the pool, this would allow workers to run as long as there is a thread available to run them, instead of having a static allocation of threads to workers.

This won't work because a worker will block in futexWait, hogging that thread. The typical case for asm.js programs will be for workers to run their own event loop, using futexWait to block until data is available (in shared memory). The thread will be unavailable at that point, by design. No other worker can use it, even if the worker is blocked.

I suppose the futexWait could surrender the thread. But forward-progress guarantees probably precludes this kind of solution unless there is also some kind of timeslicing (green threads, whatever) involved to make sure that a thread that can run will eventually run.

[lars-t-hansen]

Closing this because it's not relevant for the TC39 work and Mozilla tracks the issue locally.

I filed a bug against HTML to allow discussion of worker resource management: whatwg/html#851.