As far as I can tell, if you do `emscripten_sleep_with_yield()` then you
can't call any of your EXPORTED_FUNCTIONS during that yield.
The error message you get when you try describes what appears to be an
undocumented ability to cwrap your functions as being `{async: true}`. But
this doesn't spin up another emterpreter and allow you to call the function
during an `emscripten_sleep_with_yield()`, it just makes that function's
interface return a promise (for all calls).
I'm wondering what the technical limitation would be on being willing to
start another emterpreter stack? Sure, you've got code sitting around in
another emterpreter suspended state, but it is suspended...so why should
that stop you from being able to call some of your EXPORTED_FUNCTIONS if
they do work you need? If you're doing it on accident instead of on
purpose, it might be worth controlling with a switch like with the `{async:
true}`, to avoid creating multiple emterpreters willy-nilly. So maybe
`{spawn: true}`. (Though how expensive is an emterpreter state, in
practice?)
In my case, I have a handle type exposed to JavaScript, and there are a lot
of functions for poking and prodding at these handles. Some more
heavy-handed operations use emscripten_sleep_with_yield(), to do
synchronous UI feedback. But during the handlers that run while that's
happening, it would be very nice to have access to the set of functions for
doing the handle manipulation.
Best,
--Brian
--
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.
