Web Workers API
developer.mozilla.org
Web Workers API
1–10 of 47 posts
Re: Web Workers API
#2Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
Re: Web Workers API
#3Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
Any context? Is there a specific reason to post this now? Web workers aren't new to Firefox, are they?
Re: Web Workers API
#4Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
Any context? Is there a specific reason to post this now? Web workers aren't new to Firefox, are they?
There was a discussion in another thread about Apple stifling PWAs on iOS.
One point was, web workers aren't supported correctly.
Re: Web Workers API
#5Earlier quoted context omitted.
Any context? Is there a specific reason to post this now? Web workers aren't new to Firefox, are they?
There was a discussion in another thread about Apple stifling PWAs on iOS. One point was, web workers aren't supported correctly.
IIRC normal workers are supported (dedicated workers) but shared workers are not. Service workers are "supported" but some features that are pretty critical (like push notifications) are not.
Re: Web Workers API
#6Two 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 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!
Re: Web Workers API
#7Earlier quoted context omitted.
Any context? Is there a specific reason to post this now? Web workers aren't new to Firefox, are they?
There was a discussion in another thread about Apple stifling PWAs on iOS. One point was, web workers aren't supported correctly.
I believe this is the other thread: https://news.ycombinator.com/item?id=29440457
Re: Web Workers API
#8Two 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).
Re: Web Workers API
#9Two 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 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.
Re: Web Workers API
#10Earlier quoted context omitted.
Any context? Is there a specific reason to post this now? Web workers aren't new to Firefox, are they?
There was a discussion in another thread about Apple stifling PWAs on iOS. One point was, web workers aren't supported correctly.
Also I think push notifications are not supported.