[JSPI] Pause / resume main loop before executing an async functions (matching behavior of ASYNCIFY=1)

[inolen]

Seems straight forward, but would appreciate someone more familiar with this code sanity checking.

[sbc100]

Seems reasonable yes. Maybe we can write a test for this the runs in both modes?

[sbc100]

I wonder if we should put these 2 lines in the finally block? Then we don't need t new res variable I think.

[inolen]

Added a JSPI specific test, I'm not quite sure the best way to have that run for both modes.

Hate adding tests with sleeps, but not sure of a better way to test that here.

[sbc100]

I think you can use @with_asyncify_and_jspi here to get both modes.

Then maybe the test itself should be called test_asyncify_mainloop?

[sbc100]

No space inside braces.

[inolen]

Just realized this is failing because of a change I didn't commit, but I'm not sure if you want this right now -

diff --git a/src/lib/libeventloop.js b/src/lib/libeventloop.js
index ad59b9262..3646198a2 100644
--- a/src/lib/libeventloop.js
+++ b/src/lib/libeventloop.js
@@ -378,6 +378,9 @@ LibraryJSEventLoop = {
   emscripten_set_main_loop__deps: ['$setMainLoop'],
   emscripten_set_main_loop: (func, fps, simulateInfiniteLoop) => {
     var iterFunc = {{{ makeDynCall('v', 'func') }}};
+#if JSPI
+    iterFunc = WebAssembly.promising(iterFunc);
+#endif
     setMainLoop(iterFunc, fps, simulateInfiniteLoop);
   },

I believe I had read some chatter here somewhere about automating this vs sprinkling it around everywhere.

[sbc100]

Just realized this is failing because of a change I didn't commit, but I'm not sure if you want this right now -

diff --git a/src/lib/libeventloop.js b/src/lib/libeventloop.js
index ad59b9262..3646198a2 100644
--- a/src/lib/libeventloop.js
+++ b/src/lib/libeventloop.js
@@ -378,6 +378,9 @@ LibraryJSEventLoop = {
   emscripten_set_main_loop__deps: ['$setMainLoop'],
   emscripten_set_main_loop: (func, fps, simulateInfiniteLoop) => {
     var iterFunc = {{{ makeDynCall('v', 'func') }}};
+#if JSPI
+    iterFunc = WebAssembly.promising(iterFunc);
+#endif
     setMainLoop(iterFunc, fps, simulateInfiniteLoop);
   },

I believe I had read some chatter here somewhere about automating this vs sprinkling it around everywhere.

Isn't the solution here to make sure the interFunc is in JSPI_EXPORTS? @brendandahl

[inolen]

Hmm, I tried adding a '-sJSPI_EXPORTS=loop' into the cflags variable there, but I can't get that function to show up in the exports array passed to instrumentWasmExports.

Ah, that finally worked if I also added '-sEXPORTED_FUNCTIONS=_main,_loop'.

[inolen]

Oops, somehow had rebased on an ancient branch, fixed now.

[inolen]

Adding a note here - Asyncify.handleAsync also needs to be called for all async syscalls.

Without doing so, they run into the same problem that's tested here when using EM_ASYNC_JS - multiple frames can incorrectly pile up if the syscall waits.

[sbc100]

Adding a note here - Asyncify.handleAsync also needs to be called for all async syscalls.

Without doing so, they run into the same problem that's tested here when using EM_ASYNC_JS - multiple frames can incorrectly pile up if the syscall waits.

EM_ASYNC_JS automatically adds Asyncify.handleAsync, right?

As does __async: auto. What other syscalls are you referring too that are async but don't contains Asyncify.handleAsync?

[inolen]

EM_ASYNC_JS automatically adds Asyncify.handleAsync, right?

Yep.

As does __async: auto. What other syscalls are you referring too that are async but don't contains Asyncify.handleAsync?

Does __async: auto wrap the syscall in Asyncify.handleAsync? The branch I was working with was a month or so old (no async: auto, just async: true iirc), and at least select() was not being automatically wrapped (and I didn't see code for doing that). Edit: Looks like yes it does as of bc217ce, so that note can be ignored :)