I built a little golang playground using web workers and WASM. It's nice to not hang the UI thread. https://app.qvault.io/playground/go
Web Workers API
11–20 of 47 posts
Re: Web Workers API
#12Two 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…
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?
Re: Web Workers API
#13Two 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…
> 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 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.
Re: Web Workers API
#14Two 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…
Atomics.wait() cannot be called on the main thread (i.e. when your global is a Window object).
There is Atomics.waitAsync which can be used on the main thread and just returns a promise. It is shipped at least in chrome.
Re: Web Workers API
#15is web worker really good for some costly processes? would it really be useful for a dashboard with sample instant data flow?
Re: Web Workers API
#16Two 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…
In #2 you use Atomics.wait in the Worker instead and then it can signal the main thread when done.
We use this to convert async browser APIs to service synchronous callbacks that our C library compiled to WebAssembly expects.
Re: Web Workers API
#17If you're interested in leveraging web workers easily for repetitive compute-heavy tasks in a webapp, i've built a little library that takes care of launching and managing worker threads for you: https://github.com/GitSquared/rinzler
Re: Web Workers API
#18If you're interested in leveraging web workers easily for repetitive compute-heavy tasks in a webapp, i've built a little library that takes care of launching and managing worker threads for you: https://github.com/GitSquared/rinzler
Nice. Do you also support SharedArrayBuffers or does everything need to be serializable that is sent to/from WebWorkers?
Re: Web Workers API
#19If you're interested in leveraging web workers easily for repetitive compute-heavy tasks in a webapp, i've built a little library that takes care of launching and managing worker threads for you: https://github.com/GitSquared/rinzler
Nice. Do you also support SharedArrayBuffers or does everything need to be serializable that is sent to/from WebWorkers?
By the way, I built something similar (?): A Rust library that mimics the API of the `futures-executor` crate, but each worker thread is a single WebWorker.
Re: Web Workers API
#20Hyperscript supports inline web worker definitions:
https://hyperscript.org/features/worker/
We tried to improve the API to this very cool feature.