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