emscripten-core/emscripten

docs: Improve Asyncify documentation about ignore-indirect & fiber.h

Open

#11 681 ouverte le 20 juil. 2020

Voir sur GitHub
 (12 commentaires) (0 réactions) (0 assignés)C++ (3 519 forks)batch import
asyncifygood first bughelp wanted

Métriques du dépôt

Stars
 (27 361 stars)
Métriques de merge PR
 (Merge moyen 19j 10h) (147 PRs mergées en 30 j)

Description

Edit: I've also set SDL_SetHint(SDL_HINT_EMSCRIPTEN_ASYNCIFY, "0"); to try to disable other potential sources of asynchronous events.

Ref: https://github.com/Wizcorp/byuu-web/blob/master/libco/emscripten_fiber.c

I've been working on the project above for a few months, and early on in the process we've tried to refactor some of the code to avoid context switching overall as it appeared to have an unacceptable overhead. However, each core we add requires tedious porting work, work I'm eager to get rid of if possible.

I've recently read that said overhead can be mitigated by being more specific about what functions can unwind the stack; therefore, I've experimented with using build flags such as -s ASYNCIFY_IGNORE_INDIRECT, but unfortunately I've only been met with exception thrown: RuntimeError: unreachable so far (the reported method where the error occurs appear to differ based on what I feed in ASYNCIFY_IMPORTS/ASYNCIFY_ADD - however, none of those function hold async code).

I have one other place in the code where we use async code, but I am not currently using this code path; as it stand, only the fiber.h API (and perhaps emscripten_set_main_loop?) should be calling code asynchronously.

My questions would be as follow:

  1. Does it make sense to try to optimize the above referred code through ASYNCIFY_IGNORE_INDIRECT or other means?
  2. If the answer to the above is yes, what would be the best way to go about it?
  3. Are there any caveats to using emscripten_set_main_loop which would block the kind of optimizations I'm attempting?

Guide contributeur