Conversation
| // EM_ASM support | ||
|
|
||
| std::string handleAsmConst(const Instruction *CI) { | ||
| // callType is one of "", "sync_on_main_thread_" or "async_on_main_thread_" and specifies |
There was a problem hiding this comment.
how about an enum for the call type?
There was a problem hiding this comment.
Enum sounds fine, I'll change to that.
|
Is there a writeup of the direction this is going? Stuff like this would need to happen in the wasm backend too, so deserves a wide discussion. |
|
I'm quite complete with the multithreading work now, and this PR ended up being the only change needed on the LLVM side. The remaining changes were mostly to jsifier, which processes the proxying model for JS libraries. The model is the same for JS libraries and EM_ASM blocks. I'll ping on this again when I have the Emscripten side PR cleaned up for looks. |
juj
force-pushed
the
em_asm_calltype
branch
from
04f33e4 to
ef488e5
Compare
…in VarArgs expansion.
|
This PR should now be good to merge. Updated this along with matching emscripten-core/emscripten#5544 to address review comments. CC @kripken, @jgravelle-google . |
|
No concerns from me. |
|
Looks reasonable to me |
|
Perfect! |
3 participants
This expands
EM_ASMhandling to allow specifying how the JS code is run in multithreaded environment: a) locally (synchronously) on the calling thread, b) synchronously proxied to main browser thread, or c) asynchronously proxied to main browser thread.This needs a matching Emscripten side PR to land, I'll get to that at some point.