On Wednesday, October 10, 2018 at 5:07:47 AM UTC-4, Hostile Fork wrote:
>
> I'm trying out converting a previously-emterpreted project to the
> SharedArrayBuffer and USE_PTHREADS=1. One of the first things I tried out
> with that was MAIN_THREAD_EM_ASM().
>
> However, ENVIRONMENT='worker', and when I use it then it still runs on the
> worker.
>
> What I'd guess then is that "MAIN_THREAD_" refers not to the browser's UI
> thread, but rather wherever the emscripten'd code was launched ("the main()
> thread")?
>
In my evolving understanding, you can't really share your
EXPORTED_FUNCTIONS between a web worker and the GUI in the browser. While
I imagine it's theoretically possible (?), you'd have to proxy the entirety
of the emscripten Module infrastructure which backs them...and that's a lot
of code.
Hence if you ever want to see a mixture of your EXPORTED_FUNCTIONS with
code that does something like browser DOM manipulation, that forces you
into ENVIRONMENT='web'. SharedArrayBuffer doesn't change that equation.
I gather this prohibits some wishful thinking I had about what
MAIN_THREAD_EM_ASM() and the PTHREAD build switch or any of those "proxy"
compile switches might do. I wanted to have a library of entry points most
of which were designed to be used on either the worker or GUI, with some
entry points that would kick over and "automagically" run some JavaScript
on the GUI thread. The stylization would be such that both wouldn't be
running the emscripten code at the same time, they'd always be
synchronously waiting on each other while requesting back and forth...
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
