-
Notifications
You must be signed in to change notification settings - Fork 0
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
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
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)