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