SharedWorker Atomics #7
Conversation
1cb1378 to
f942c7e
Compare
f942c7e to
4e1e173
Compare
|
... and "who am I kidding" ... I've just realized my polyfill works perfectly fine but native implementation wouldn't, accordingly with this SO answer, which also makes somehow sense ... back to the whiteboard then, SharedWorker in here should be patched no matter what, it's not a SAB affair, it never was 🤦 |
|
Wait, don't tell me your plan is use this polyfill for shared worker sql.js lib ? 😃 So curious! |
|
@khanhicetea the thing is, once this works out of the box the whole API can be forwarded asynchronously without me needing to maintain or update it, including statements and whatnot, it should "just work" ... except the Currently though, I am not sure if this can ever possibly work but I am trying ... good thing it's a PR I can close and forget about if I'll fail. |
75cf962 to
e12e842
Compare
|
OK, latest works as expected with or without SharedArrayBuffer around, which is cool and everything but before making this library bigger than it needs to be, I'd like to temporarily publish this with a different name and see how well it plays, or breaks, with existent libraries based on this approach ... hence it'd be draft for a while, or maybe forever, who knows. |
e12e842 to
e42de9a
Compare
|
Published as |
79a9574 to
ff634be
Compare
|
damn it ... with latest "lazy all the things" approach I really think this should go in ... |
ff634be to
b87883a
Compare
b87883a to
fd0379f
Compare
|
@khanhicetea btw, sql.js in SharedWorker is already a thing ... here I am trying to see if I can go beyond that library but SharedWorkers are a weird beast ... just the fact you need same-origin policy no matter what makes these less portable for libraries' authors. |
2c1e509 to
b1c7556
Compare
b1c7556 to
1ac7f15
Compare
2885a27 to
7fe2fd1
Compare
So you mean the shared-worker script must be hosted in same-origin to work , right ? Or the headers : 😄 My browser API knowledge level is a step far behind yours :( So sometimes I really try to understand what you do, but end with guessing about basic concepts what I currently know. |
this project is the reason you shouldn't care because it enables SAB even when those headers are not defined, falling back with either mini-coi or XHR when sync SAB from workers is desired.
AFAIK yes, and those headers might not be enough ... those are also not necessary for SharedWorker if such file comes already from the same origin ... having a worker file in your assets is common enough, no reason to panic for this use case ... but as that's async only and SAB cannot possibly work (it's patched in here) you really could use sabayon as SharedWorker and call it a day ... actually this might be a good reason already to convince me this PR should land officially. |
7fe2fd1 to
75257a7
Compare
|
Somehow a change of direction ... as SharedWorker can't literallly deal with SAB, I wonder if a simple |
|
Please forgive me if I'm not being helpful here, but I wonder if the Broadcast Channel API would be helpful or perhaps even more appropriate here? Particularly since this is for using SharedWorkers, which are typically used across many tabs, so Broadcast Channel would allow for easy communication across all of them. I can imagine that it has particular limitations or extra overhead though, so perhaps its not appropriate for what youre trying to do |
|
I’m not sure I’m following … but within the sharedworker you can grab ports and do whatever you like, this module is to enable Atomics and SAB and broadcasted atomic operation makes no sense to me because you need to create a SAB and that cannot be broadcasted … as others wouldn’t have the SAB in their code, or promises waiting for its notification… but again, you can add broadcast yourself if needed |
|
Again, apologies - evidently my suggestion was not helpful. Please carry on! |
|
as update, we're here: DallasHoff/sqlocal#39 (comment) my polyfill works over something that shouldn't and I don't think that's a way forward ... rather a trap for the future of this module or any other module based on this. Let's see how it goes in there though ... we're sharing the same goal, I am confident something will happen sooner than later. |
This MR would like to introduce Atomics for the SharedWorker use case, considering the folowing caveats:
Atomics.notifyandAtomics.waitAsyncare currently implemented and I believe that's the right thing to dowaitsynchronously, it's only the SharedWorker that won't allow blockingwaitin it.portis automatically started once a SharedWorker is created (arguably the most awkward API I've seen to date).That's it, once this is tested and merged, it opens doors to coincident project as there could be things, at that point, that were previously not possible, from either workers or the main thread.