-
Couldn't load subscription status.
- 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
| } | ||
|
|
||
| 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
emscripten_malloc_wasm_workerandemscripten_create_wasm_workerfunctionsadapted to the nodejs environment and
modified the core related tests.