-
Notifications
You must be signed in to change notification settings - Fork 0
Esm off thread unlock worker #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Esm off thread unlock worker #2
Conversation
|
There are still failures related to the |
c8ea77a to
2e60363
Compare
b07e12a to
a04dcae
Compare
|
@targos I rebased However one of the failures on this branch is a timeout, which I’ve grown to dread from the other branch; on the other branch at least, those have always meant that an exception was being thrown inside the worker that never got transferred up to the main thread to be re-thrown there to crash the process. I don’t know if maybe there could be other reasons for a timeout now that the main thread isn’t locked, but ideally we’d fix the timeout (even if the test in question still fails) before merging this in. The timing out test is Also I’m wondering if we can separate the refactor to use |
a04dcae to
b97e08e
Compare
b97e08e to
1a7cbd4
Compare
JakobJingleheimer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This looks very promising and far less arcane than Atomics
| // Send the method response (or exception) to the main thread | ||
| try { | ||
| TypedArrayPrototypeSet(data, serializedResponse); | ||
| syncCommPort.postMessage(response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure the cause of the huge performance difference between SharedArrayBuffer and postMessage() is because with the SAB, it's a single shared memory space (so the transfer across threads is merely a context switch and nothing is moved/copied); but with postMessage(), when only the first arg is used, the response is copied (which is relatively expensive, on top of consuming double the space).
I think if you instead transfer the response via the 2nd param, we'll see more similar (better) performance with postMessage()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 2nd param of postMessage can only be used with transferable objects. response is not transferable. I still haven't seen any benchmark or perf numbers so I'm not really inclined to talk about it just based on assumptions.
dbd039f to
1e6c05e
Compare
3f10022 to
f224714
Compare
use postMessage from the main thread instead of atomics to signal the worker
f224714 to
88eac69
Compare
I compared the test results before and after the changes (deleted identical output).
Before (16 failures)
After (18 failures)