The emscripten runtime is queuing calls to some functions such as 
getenv(...) to run in the main browser thread. Since we launch the compiled 
module from a worker (and not from the browser thread), we also cannot 
queue anything to be run in the main browser thread. AFAICS, this also 
affects calls to mundane stuff like printf(...), which definitely does not 
need to run in the browser thread.

What would IMHO be ideal is a switch in settings.js that allows me to 
override emscripten's default behaviour of dispatching calls to the browser 
thread. Or even better: the emscripten runtime automatically detects that 
we invoke "callMain(...)" from a worker and then also tries to dispatch the 
calls there. THis will obviously limit access to features like the DOM, 
WebAudio, etc. Not a problem for us anyway, our compiled code is headless.

On Wednesday, March 13, 2019 at 5:02:59 AM UTC+10, Sam Clegg wrote:
>
> Can you explain you use case a little more?  It sounds like you want 
> to queue some work to be done on you main runtime thread?    Is this 
> work you are queuing yourself or work that the emscripten runtime is 
> queuing?  If its the emscripten runtime than presumably it does need 
> this the work to be performed on the main browser thread.   Is there 
> some reason why your main browser thread is not performing the queued 
> work? 
>
> On Fri, Mar 8, 2019 at 7:23 PM Soeren Balko <[email protected] 
> <javascript:>> wrote: 
> > 
> > I suspected as much, but its unfortunate nevertheless. We do not run any 
> "privileged" operations that would require access to APIs only available in 
> the main thread (eg., DOM manipulation, WebAudio, canvas/WebGL etc.). Only 
> after I patched `library_pthread.c` to check for the "main runtime thread", 
> which in our case runs in a worker, I got it to work. IMHO, this should 
> become a compiler setting. I may submit a pull request in this regard. 
> > 
> > On Saturday, March 9, 2019 at 2:38:13 AM UTC+10, Sam Clegg wrote: 
> >> 
> >> I imagine that is because processing these queued tasks needs to 
> >> happen on the main browser thread.  This is generally the "special" 
> >> and "privileged" thread.   This is where all the web APIs are 
> >> available and the browser even loop runs.  This the only thread that 
> >> can't actually block on atomic memory. 
> >> 
> >> The main runtime thread can sometimes not be on the main browser 
> >> thread (as you note with PROXY_TO_PTHREAD=1) and in those cases its 
> >> not capable of performs the actions assocated with main browser 
> >> thread. 
> >> 
> >> Put another way: Places that post work to the "main" thread are doing 
> >> so because they need the code to run on the main browser thread. 
> >> 
> >> This is my understanding.. but I could be wrong. 
> >> 
> >> cheers, 
> >> sam 
> >> 
> >> On Wed, Mar 6, 2019 at 11:25 PM Soeren Balko <[email protected]> wrote: 
> >> > 
> >> > We are playing around with Emscripten's pthread support for 
> WebAssembly, where we call the module's callMain from a worker and use the 
> PROXY_TO_PTHREAD=1 setting to have it spin up a proxy thread for main. 
> >> > 
> >> > However, we noticed that the actual main worker does never process 
> any calls that are dispatched from the proxy thread. After a bit of poking 
> around, we found that emscripten_main_thread_process_queued_calls (in 
> library_pthread.c) checks that it is in the main browser thread 
> (emscripten_is_main_browser_thread). Why is that so? Wouldn't it be 
> sufficient to check for emscripten_is_main_runtime_thread? 
> >> > 
> >> > Soeren 
> >> > 
> >> > -- 
> >> > 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] 
> <javascript:>. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > 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] <javascript:>. 
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.

Reply via email to