Automatically asyncify a main with arguments. #18252
Conversation
test/test_core.py
Outdated
| @with_asyncify_and_stack_switching | ||
| def test_async_main(self): | ||
| # needs to flush stdio streams | ||
| self.set_setting('EXIT_RUNTIME') |
There was a problem hiding this comment.
If you add a newline to the end of the printf then maybe you can remove this line?
| #include <stdio.h> | ||
| #include <emscripten.h> | ||
| int main(int argc, char **argv) { | ||
| emscripten_sleep(1); |
There was a problem hiding this comment.
use usleep(1000) instead and avoid the emscripten-specific function/include? Maybe not worth it?
There was a problem hiding this comment.
emscripten_sleep is Asyncify-enabled function (it suspends via Asyncify), while usleep, IIRC, actually blocks the main thread with a spin-loop, so wouldn't be suitable for a test.
There was a problem hiding this comment.
If true, that seems like something we might want to fix. Shouldn't all sleep functions should be Asyncify-enabled when running in Asyncify mode no?
Looking at the details it does looks like you are right though usleep -> nanosleep -> emscripten_thread_sleep -> emscripten_futex_wait, and as far as I know emscripten_futex_wait is not Asyncify-enabled.
I wonder if emscripten_thread_sleep or maybe even emscripten_futex_wait should be Asyncify-enabled?
There was a problem hiding this comment.
(I guess emscripten_thread_sleep and not emscripten_futex_wait.. since the later is used in many different places, but emscripten_thread_sleep is basically just used to implement clock_nanosleep).
There was a problem hiding this comment.
Shouldn't all sleep functions should be Asyncify-enabled when running in Asyncify mode no?
Heh yeah I think I suggested that a while ago too but can't find an issue.
Same for other APIs that do potentially async work - currently we have a somewhat inconsistent mix of "will block while waiting for the result", "will run async on a separate thread" and "will run async via Asyncify", e.g. see #12255.
No description provided.