Remove ASYNCIFY?

[Alon Zakai]

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

[Jukka Jylänki]

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 box with ASMFS (I have a PR adding that
support in the pipes). So if someone is kind of on the edge of
"perhaps I might need this" - there's a superior build option coming -
use the linker flag -s PROXY_TO_PTHREAD=1 in current incoming to
utilize this already now in its early stages.

> --
> 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 emscripten-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Александр Гурьянов]

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 emterpreter porting is super easy (but result is slow). How new
superior option will avoid this cycles? I want to try it.

[Jukka Jylänki]

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 its support with Wasm, OffscreenCanvas and
HTML5 event proxying that hopefully should land soon.

[Aidan Hobson Sayers]

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 exceptions (emterpreter does).

>> email to emscripten-discuss+unsub...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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 emscripten-discuss+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
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 emscripten-discuss+unsub...@googlegroups.com.

[Soeren Balko]

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 SharedArrayBuffer/Atomics APIs OR the upcoming multithreading support in WebAssembly is the cleaner approach. 

Soeren