Well, in my C++ pthread tick function I tried performing a call to emscripten_cancel_main_loop() and then called emscripten_set_main_loop_arg(WasmHTTPRequestMainLoop, this, 10, 0), however my new main loop for this thread is never called, and my pthread tick function kept ticking.
I would expect my new C main loop function to take over for my old pthread C++ main loop, but in fact nothing happened. It just kept calling my original pthread C++ tick function. I don't see any example code in the emscripten SDK that covers pthreads and asynchronous JavaScript, so I doubt this is something that's even tested, which seems unfortunate. Again, Asyncify doesn't sound like a solution, especially not if I have to write some JavaScript system to multiplex N number of asynchronous JavaScript functions. It'll bloat the game code, or make debugging impossible, and I still don't get truly asynchronous JavaScript out of it (I would consider one function running at a time on a multi-core device to be pseudo-asynchronous anyway). It's quickly looking like right now we can't have asynchronous JavaScript code if we use pthreads. :( On Thursday, March 26, 2020 at 11:24:39 AM UTC-7, Alon Zakai wrote: > > > I'm not sure I understand how emscripten_set_main_loop() will help my > JavaScript execute the async code... are you saying that the compiled code > in each thread is blocking the JavaScript code? > > Yes, see > > > https://emscripten.org/docs/porting/emscripten-runtime-environment.html?#browser-main-loop > > if you have a "while (1)" loop as in the example there, then it never > exits back to the JS event loop. All execution has to stop for that to > happen. That's the same on the main thread and on workers, and the solution > can be the same, as described there. > > About Asyncify: I think most of your worries are not an issue (it works > with pthreads, and you can implement multiple async events at once, but you > need to add a little JS layer yourself to multiplex them, etc.). But if you > can just switch to using emscripten_set_main_loop() or some other async way > of doing your main loop, that would be much simpler and much better. > > > > On Wed, Mar 25, 2020 at 5:51 PM Kevin McGrath <[email protected] > <javascript:>> wrote: > >> Ah! Thanks for the details! I looked into Asyncify and ruled it out >> because of this from the emscripten documentation: >> >> It is not safe to start an async operation while another is already >>> running. The first must complete before the second begins. >> >> >> That would mean one HTTP request at a time, one after another, and any >> time we want to use Asyncify for any other async JavaScript tasks we may >> run into trouble that would be a nightmare to debug. Plus there's more >> issues described in that doc, such as if we get an event (like a keypress) >> while the async JavaScript is running it doesn't sound too stable when it >> calls into compiled code. Lastly, they mention that you should always run >> optimized builds if you're using Asyncify, which will not be fun to debug. >> Taking all of that into consideration, it didn't sound like a good option >> to me, especially since I wasn't sure it would work in the first place with >> USE_PTHREADS=1. >> >> I'm not sure I understand how emscripten_set_main_loop() will help my >> JavaScript execute the async code... are you saying that the compiled code >> in each thread is blocking the JavaScript code? >> >> Sorry for so many questions, I'm very new to JavaScript and know very >> little about its internal workings. Also seems impossible to Google for >> this kind of stuff. >> >> Thank you! >> >> >> On Wednesday, March 25, 2020 at 4:39:29 PM UTC-7, Alon Zakai wrote: >>> >>> emscripten_thread_sleep() will check the pthread event queue, which >>> means it can receive C messages from other threads - those are synchronized >>> using shared memory. However, it can't help with JS events, as to get those >>> to happen you need to actually return to the main JS event loop. The >>> browser won't run those events otherwise. >>> >>> To do that, you can use Asyncify ( >>> https://emscripten.org/docs/porting/asyncify.html) and >>> emscripten_sleep(). Or, you can manually return to the main event loop >>> yourself, replacing an infinite event loop with an >>> emscripten_set_main_loop() etc. >>> >>> On Wed, Mar 25, 2020 at 1:56 PM Kevin McGrath <[email protected]> >>> wrote: >>> >>>> Hello! >>>> >>>> I'm hoping someone has already run into this before and can tell me >>>> what I'm doing wrong... >>>> >>>> I have a JavaScript function I'm calling from a C++ multi-threaded game >>>> that is designed to perform an async HTTP fetch. >>>> >>>> I'm building the game using USE_PTHREADS=1 and PROXY_TO_PTHREAD=1 and >>>> I've tried both having the JavaScript function embedded in a EM_JS() and >>>> in >>>> a --js-library. The C++ code sparks off a pthread and calls into the >>>> JavaScript function, and that JavaScript code executes and then returns >>>> back to the C++ code. What doesn't work is any of the Promise / await >>>> code, nothing is executing in those code blocks. >>>> >>>> I've tried calling emscripten_thread_sleep() from the C++ code, which >>>> is still executing in the thread waiting on the JavaScript asynchronous >>>> code to call it back, it just never happens. The network request is just >>>> marked as "(pending)" in Chrome and never changes. >>>> >>>> So my question is, what's the right way to run Promise/async/await code >>>> in a WebAssembly pthread/Web Worker? >>>> >>>> Thank you!! >>>> >>>> -- >>>> 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]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/emscripten-discuss/aecd43c5-6662-4d7d-bb8c-15461e75522e%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/emscripten-discuss/aecd43c5-6662-4d7d-bb8c-15461e75522e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/fe4d60af-6a74-40e6-b37f-31a04eb34afd%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/fe4d60af-6a74-40e6-b37f-31a04eb34afd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/d4918085-f6bc-4912-94a1-3412763525fe%40googlegroups.com.
