Should named workers automatically fallback to async only usage? #2112
Replies: 2 comments 1 reply
-
|
To whom it might concern, this is ready to land in polyscript and changes are pretty minimal too: pyscript/polyscript#107 |
Beta Was this translation helpful? Give feedback.
-
|
P.S. an alternative to this would need a whole refactoring of coincident where, if no SAB is possible, synchronous blocking requests could be used and intercepted via ServiceWorker but I haven't explored yet this field, although I've been told it might work. The dance there would be that if no SAB and no Atomics.wait is possible, the worker uses XMLHttpRequest in a synchronous way to post some sort of JSON that the ServiceWorker would understands and redirect as is to the main thread to then await the result and reply back. I don't know about performance implications but I kinda feel that would still be better than having all these issues around Workers with COI enabled or disabled ... from the main though, the contract won't change, it will still require This is all theoretical but I'd like to explore the field a bit as it might make everyone happy if performance will be acceptable. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I needed to be sure it was possible or not to have sync like operations through a sync
Accordingly to my measurements done on my machine a basic echo form a worker that goes through a service worker, that reaches the actually visible client and send data to it to then understand that data on main and post back a result to then forward it back as Response takes ~1.5ms ... what bothers me the most is that in order to do this I still need an explicit Service Worker registered to intercept only those calls but the moment I need a Service Worker to solve anything is the moment I believe True that from an academic perspective there's gotta be a way to keep everything else untouched and channel only these exchanges but unfortunately that's not the case and messing with too many service workers might also be problematic. I thought it was OK to share ... I actually like what I am seeing but it's a bit slow and it doesn't solve the real issue: a service worker is still needed to fix what mini-coi service worker could fix better (by enabling SharedArrayBuffer). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Because it's a new thing (not even released - yet) and because @mchilvers expressed the desire to make
sync_main_only = Truethe default when these named workers are used (not implemented - yet) I would like to discuss a better idea behind named workers, an idea that would then collect feedback from our users and maybe help us understanding if it's worth doing the same with any worker in general, not just the named one.Proposal
When a worker is named, we automatically fallback to
sync_main_only = Trueonly ifSharedArrayBufferis not usable and also only if thatsync_main_onlywas not explicitly set.This should cover all scenarios yet it would relax workers without necessarily asking users to setup special headers or use
mini-coiwhen no access to the DOM or main thread utilities is needed on the worker side.The covered scenarios will then be:
sync_main_onlyis explicitly set, nothing changessync_main_onlyis not set and the SharedArrayBuffer class is usable, nothing changessync_main_onlyis not set and the SharedArrayBuffer class is not usable, we fallback instead of throwing errors (current MR simply warns users no SAB is used, a fallback would be used)This behavior would initially be enabled only for named workers on the main thread instead of suddenly changing expected thrown errors when SAB is desired but not available and the
sync_main_onlyflag is not explicitly set toTrue.@JeffersGlass @ntoll @fpliger any thoughts or objection about this? Thanks!
Beta Was this translation helpful? Give feedback.
All reactions