21–30 of 47 posts
is web worker really good for some costly processes? would it really be useful for a dashboard with sample instant data flow?
Earlier quoted context omitted.
Atomics.wait() cannot be called on the main thread (i.e. when your global is a Window object).
It works fine both in Node and Deno. I haven't tested this out on browsers though, is that supposed to throw even if SharedArrayBuffer is enabled?
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!
Earlier quoted context omitted.
> and then use Atomics.wait on the main thread to block 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 whe…
I should check what's the status with Atomics.wait on Chrome, currently it seems to work fine under both Node and Deno. 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 Wo…
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.
is web worker really good for some costly processes? would it really be useful for a dashboard with sample instant data flow?
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.
A little known annoying detail of web workers is that passing large data to them via postMessage is incredibly slow. The browser has to convert your javascript object into some sort of internal binary format and it slows down the thread that's doing the sending.
[1] https://developers.google.com/web/updates/2011/12/Transferab... [2] https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...
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.
Two lesser known really cool things about Web Workers: 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 t…
The fact that creating a worker requires you to pass a module (file) name makes them extremely unergonomic to use. 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 restr…