Web Workers API
developer.mozilla.org
developer.mozilla.org
1. They kind of allow for stopping synchronous operations, example: some regexes have "catastrophic backtracking", executing them will take a really long time, so what do you do if you have to execute user-provided regexes, especially if on the server? Detecting potentially catastrophic regexes is tough, reimplementing the regex engine in order to make it yield to the main thread frequently so that you can stop it is super tough, so what's the solution? You can execute the regex in a Web Worker, and if you haven't received a response within some set amount of time you can just kill the Web Worker, effectively stopping the regex execution, cool!
2. They kind of allow for blocking on promises, example: normally you can't block the event loop while you are waiting for a promise to be resolved, in other words you can't make an asynchronous function synchronous, except if you use Web Workers, you can execute the asynchronous function you need on a worker, and then use Atomics.wait on the main thread to block (without melting the computer) until that function resolves, super cool!
This is a fairly difficult aspect of multithreading on the web, and it makes things more complicated than other platforms (like Node and Deno, as you mentioned). For example in emscripten's pthreads support layer there is code dedicated to do a sort of careful busy-wait when we have no other option, and all that is only for the case of the main thread.
But your point is still very relevant, just not on the main thread: if you can run your application in a worker, then you can block on Promises using another worker that does the async operation while the first worker is synchronous. And that's really useful!
The main thread is not allowed to use Atomics.wait. I’m not certain what the implementation status of this is because I’ve never used it and I have a vague feeling I heard that one browser shipped it without that restriction, but at the very least you may get a TypeError in some user agents and you can expect to in all user agents at some point in the future when they become sterner about not blocking the main thread.
As for stopping synchronous operations, I’m dubious that would actually work; without actually testing it (and I don’t have time to test it now, though I’d be interested in the result, including across various platforms), I think it’s more likely that the regexp match would be uninterruptable, and that it would just go on munching your CPU until it finished, and then terminate once it returned from the native code to the JavaScript.
I'll test out the regex thing in the following days as I need it for that exact use case, I just assumed killing the web worker would... work, hopefully that's the case otherwise I'm back to square 0 :D
---
Edit: MDN says: "The terminate() method of the Worker interface immediately terminates the Worker. This does not offer the worker an opportunity to finish its operations; it is stopped at once." so if that's not the case either the engine is wrong or the docs are wrong.
So I say my gut feeling is that the match operation won’t actually be interrupted, and I wouldn’t be inclined to depend on it actually being interrupted without explicit documentation of what aborting does, even if all environments I cared about did abort it immediately.
Seems to work in Chromium, though it looks like it might be taking a second or two to actually terminate it. It’s a bit harder to tell if it works in Firefox, because Firefox kills the regular expression within five seconds with the error from RegExpBuiltinExec “too much recursion”, but I think it is, and probably faster than Chromium, though it’s hard to be certain when just doing the lazy check of CPU usage at one second granularity.
Interesting! They must have changed something because when I published that the code looked alright, albeit with some stuff linkified.
We use this to convert async browser APIs to service synchronous callbacks that our C library compiled to WebAssembly expects.
This is clearly visible in the lack of any library ecosystem around them. We don't have any highly used threadpool or executor libraries using workers. Everyone seems to be manually setting up a worker and setting up the job scheduling logic from scratch.
All the boilerplate and restrictions really restrict its usage IMO.
I know you can pass a Blob URL but you can't write libraries this way since you risk running foul of the downstream consumer's browser CSP.
Can anybody explain how did this ever make it into the official spec and the default implementation?
The browser will make a network call to fetch your Web Worker .js file on every instantiation of your Web Worker. Instantiations of the same Web Worker "module" aren't cached, so in a thread-pool scenario your browser would be fetching the same file over and over again.
What were the people designing this even thinking? This is so wasteful and frustrating. The API simply sucks.
This and service workers. Both are... weird, to say the least
Failing to account for the thread-pool scenario, as an example, is just mind boggling.
For example, FileReader API is async in the main thread. There's an equivalent FileReaderSync for sync operations but that is only available in Web Workers. Why isn't FileReaderSync available on the main thread? Because the designers didn't want people to do things that would block the main thread.
The Web Worker argument probably went along the lines of "If we allow users to pass arbitrary function objects, they may try to do something that accesses local variables from the site where the worker is created. That is obviously an error, so we should design the API so that it can't happen. Creating a separate script creates a clear mental separation and avoids that class of error"
Personally I've written my own libraries for abstracting all this away and I'm having a blast working with workers now, maybe check them out:
- WorkTank [1]: This abstracts away the difference between browser workers and Node worker threads, it makes it easy to make worker pools, and it can transfer simple functions to a worker at runtime too.
- WorkTank loader: This abstracts away loading asynchronous function from a worker basically, you just add ".worker" to your file name and that file and all its dependencies are transparently moved to a worker (or worker pool), all the rest of the app (TS types for example) won't even notice anything happened, it just works, transparently.
You might want to check out the more popular "comlink" library too, although it didn't work for me for whatever reason when I tried it, and it doesn't support worker pools I believe.
Basically, any sort of work scheduling that you would like to do to queue high-priority messages, or have workers share a pool of work, is impossible to build with the onmessage-style of WebWorkers. It feels like an API made by someone who had read about threads once, rather than someone who's built an actual many-workers processing system like this. The event loop being unpumpable from user code feels like a giant kick in the face.
My workaround for this was to kill workers working on low-priority items, relaunch them, and resort the queue, but that all feels like a mess. Also, at some point a Chrome update made this strategy crash. I ended up just removing the WebWorker code; more trouble than it was worth for marginal code improvements.
I know that SAB and atomics add new low-level primitives to support this, but SAB is still poorly supported on widely deployed platforms. And you still need to do the serialization yourself.
https://stackoverflow.com/a/6454685/265521
And do you have a reference for the caching issue? I tried to Google it but all I found was people saying that web workers were cached too much, not that they aren't cached at all.
https://github.com/Rezmason/wireworld-player
https://rezmason.github.io/wireworld-player
As a simulation, the main thread asks a web worker to update the world state and then render the new state. By default, this happens once per requestAnimationFrame.
But there's a "Turbo" mode (its UI toggle looks like a radioactive hazard symbol) that, when activated, tells the web worker to update as often as it can per requestAnimationFrame, speeding up the simulation around 72x while keeping the main thread 100% responsive.
The decoupling of the synchronous number crunching work from the main thread has also given me a place to experiment with much more resource intensive algorithms, like https://jennyhasahat.github.io/hashlife.html , which fills an enormous cache and can advance the sim by exponential time steps.
Modifying Hashlife to run in the main thread without freezing the app is possible, but it would have made the code much more complicated, run slower, and the other cores available to web workers would have gone unused.
https://hyperscript.org/features/worker/
We tried to improve the API to this very cool feature.
One point was, web workers aren't supported correctly.
[1] https://developers.google.com/web/updates/2011/12/Transferab... [2] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...