-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix the WASM Worker cannot start in node.js environment #20188
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
Conversation
4d72e2d
to
bbf542b
Compare
909b453
to
17705e2
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.
I'll let @juj do the main review here.
7452988
to
858f974
Compare
2cfc714
to
3b0a440
Compare
2b79d96
to
1a92216
Compare
1a92216
to
b581535
Compare
cc68e65
to
0771c46
Compare
@@ -1023,3 +1035,7 @@ function getPerformanceNow() { | |||
return 'performance.now'; | |||
} | |||
} | |||
|
|||
function implicitSelf() { | |||
return ENVIRONMENT.includes('node') ? 'self.' : ''; |
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.
What happens if the environment includes both node and web and we run the result on the web? i.e. isn't choosing to use self.
or not here at compile time too early.. don't we need to decide at runtime maybe?
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.
In the web environment, it can run with or without the self.
prefix, but in the node environment, it must have the self.
prefix to run.
So I think the above code is correct.
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.
Ah I see. It looks like we have the same pattern in src/worker.js
but we simply always use self
there.
I wonder if we could find a way to avoid the self.
completely by using defineProperty
on the global object under node? Maybe that would be more code overall?
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 think this issue is the same as the issue below, it can create a separate PR after merging this to deal with these two issues together.
removeEventListener: (name, handler) => parentPort.off(name, handler), | ||
}); | ||
} | ||
#endif // ENVIRONMENT_MAY_BE_NODE |
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.
This seems like duplication of the code in src/worker.js
.. is it worth factoring out into a separate file that can be included in both places. Something like src/node_webworker_polyfill.py
?
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 think this issue is the same as the issue above, can create a separate PR after merging this to deal with these two issues together.
e13171e
to
f4c6219
Compare
3c57233
to
a23f797
Compare
a23f797
to
5412c93
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.
lgtm % comments from me. I'll leave @juj to approve
5412c93
to
0d0e9c9
Compare
0d0e9c9
to
d272679
Compare
d272679
to
b5e0782
Compare
Looks very nice, great work. I had one comment about the subtle distinction between SHARED_MEMORY and PTHREADS/WASM_WORKERS. Otherwise LGTM to land. |
let data = e.data, wasmCall = data['_wsc']; | ||
#if ENVIRONMENT_MAY_BE_NODE | ||
// In Node.js environment, message event 'e' containing the actual data sent, | ||
// while in the browser environment it's contained by 'e.data'. |
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.
Why is this the case, though? If it arrives from a Node.js or Web API then that means this workaround is necessary, but if not, then if it arrives from our own code, can we send data in the same format?
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.
Oh, reading that again, I think you're saying it's the first? We send data the same way, but Node and the Web end up providing it differently? If so then lgtm.
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.
Oh, reading that again, I think you're saying it's the first? We send data the same way, but Node and the Web end up providing it differently? If so then lgtm.
yeah, you are right! 👍
`emscripten_malloc_wasm_worker` and `emscripten_create_wasm_worker` functions adapted to the nodejs environment and modified the core related tests.
`emscripten_malloc_wasm_worker` and `emscripten_create_wasm_worker` functions adapted to the nodejs environment and modified the core related tests.
b5e0782
to
55b0af7
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.
lgtm and tests now passed.
@sbc100 did you want to take another look before we land?
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 would like see the node worker stuff factored out as a followup, but otherwise lgtm
Back in #21701 I moved the creation of wasmOffsetConvert and wasmOffset into runtime_pthread.js but I didn't update libwasm_worker.js which still uses the old name `wasmOffsetData` in its initial post message. When trying to update this just now I noticed that the offset converter (and santiizers in general) don't seem to work on `WASM_WORKERS` so this change simply disables them. The passing of `wasmOffsetData` and `wasmSourceMapData` was added back in #20188 but it doesn't looks like support for santizers was supposed to be part of that.
emscripten_malloc_wasm_worker
andemscripten_create_wasm_worker
functionsadapted to the nodejs environment and
modified the core related tests.