I loved the concept, but found it to be impractical for our code base
(heaps of function pointers), which dramatically went up in size. We ended
up using the normal event loop approach that unwinds the stack "manually".
Going forward, I believe that using a sync/async bridge that uses the
Readers may be interested in this comparison between the emterpreter and
asyncify -
https://github.com/kripken/emscripten/wiki/Emterpreter#comparison-to-asyncify
In summary, ASYNCIFY: is probably faster than emterpreter, definitely
produces larger output than emterpreter and won't work with
The new method runs the whole application in a web worker. This will
require WebAssembly multithreading to ship first, so it's still a
couple of months away from browsers having that, but you can try it
out with -s PROXY_TO_PTHREAD=1 linker option. There are a couple of
PRs coming in to improve
Hmm, I have an project (Dune 2) that uses emterpreter. The Dune 2
project, contains a lot of cycles like:
while (true) {
// do some animation stuff
// usually: shift pallete + render
}
or
while (true) {
// do read input
// for example: save game dialog (enter file name)
}
With
It's notable here that ASYNCIFY (and also EMTERPRETER) both have a
good path of becoming redundant once Wasm multithreading is available,
because then we can run all APIs synchronously for greatly simplified
porting. For example, synchronously asking stdin for input will be
possible just out of
The ASYNCIFY docs have said this for a long time now:
> This feature is experimental, and not recommended. See the Emterpreter
for a more recent option with similar functionality, that is currently
supported.
Is anyone still using it? And if so, is anyone interested to maintain it?
- Alon
--
