Future of asynchronous

[Beuc]

Hi,

Currently I use Emterpreter for my Python-based project web port (
https://renpy.beuc.net/ ).
I don't see it referenced in the "upstream" roadmap though:
https://github.com/emscripten-core/emscripten/projects/1
Is EMTERPRETIFY planned for "upstream"?

Also, what I'd really need is pthreads, but I can't find ETA for when
Mozilla or Microsoft plan to bring
SharedArrayBuffer/WebAssembly-threads/etc. back.
Any info? :)

Cheers!
Beuc

[Derek Schuff]

The future of asynchronous is the new version of Asyncify (https://emscripten.org/docs/porting/asyncify.html). It serves the same use cases as emterpreter (it operates similarly to fastcomp's old "asyncify" pass, but should be faster than that and emterpreter).

Unfortunately I don't know anything specific about Microsoft or Mozilla's threading plans. MS's Chromium-based version of Edge will inherit Chrome's site-isolation feature, so they can safely ship threads; presumably they will leave it enabled in their builds?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/406ad461-4b8e-cffb-62b3-8acd797cefcc%40beuc.net.

[Beuc]

Hi,

I know about new-asyncify.
However I understood Emterpreter wasn't ported to LLVM "yet", but now it seems it won't be at all.
(see also https://github.com/emscripten-core/emscripten/issues/9257#issuecomment-523670023 )
I'd like to know what the official plan is :)

Good point about MS Chromium Edge.
I need to test https://www.microsoftedgeinsider.com/

TBH I'd welcome a working SDL2 proxy-to-pthread (even if it worked only for chrome-likes) more than another stack-unwind emulation.

Cheers!
Sylvain

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAAEAhvdgBaJZpA%2BfpjFPHUeJFCk8d-FwCeXeuULKrOTtKdd-Tg%40mail.gmail.com.

[Sam Clegg]

On Thu, Aug 22, 2019 at 8:01 AM Beuc <be...@beuc.net> wrote:
>
> Hi,
>

> I know about new-asyncify.
> However I understood Emterpreter wasn't ported to LLVM "yet", but now it seems it won't be at all.
> (see also https://github.com/emscripten-core/emscripten/issues/9257#issuecomment-523670023 )
> I'd like to know what the official plan is :)

I think the idea is that asyncify subsumes all the use cases that
Emterpreter previously did. Is there some use case you have that
asyncify doesn't handle?

> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/524047cf-6173-9397-28ea-ee57125c3029%40beuc.net.

[Beuc]

Hi,

On Thu, Aug 22, 2019 at 10:18:44AM -0700, 'Sam Clegg' via emscripten-discuss wrote:
> On Thu, Aug 22, 2019 at 8:01 AM Beuc <be...@beuc.net> wrote:
> > I know about new-asyncify.
> > However I understood Emterpreter wasn't ported to LLVM "yet", but now it seems it won't be at all.
> > (see also https://github.com/emscripten-core/emscripten/issues/9257#issuecomment-523670023 )
> > I'd like to know what the official plan is :)
>
> I think the idea is that asyncify subsumes all the use cases that
> Emterpreter previously did.

It looks like no one knows for sure ;)

> Is there some use case you have that asyncify doesn't handle?

I had answered you in the link above :)

- debug capacity: Emterpreter provides a detailed stack trace whenever
trying to pause in the wrong place, which is a must-have to populate
the WHITELIST in complex code with indirect calls (e.g. Python);
here AFAICT the ASYNCIFY'd application will just skip the
emscripten_sleep() and crash mysteriously later.

- pattern-matching in WHITELIST
(which I had implemented for Emterpreter)

In addition, 1.38.42-upstream fails to compile one of my dependencies:
https://github.com/emscripten-core/emscripten/issues/9317
so I cannot do a full-scale test.

More generally, it took me months, lots of reports, lots of patches
and several work-arounds to get Emterpreter stable enough for
RenPyWeb's needs. Consequently I was hoping to avoid doing that again
and reserve my time for a SDL2 proxy-to-pthread switch/contribution,
should the time come.

[Alon Zakai]

On Sun, Aug 25, 2019 at 2:21 PM Beuc <be...@beuc.net> wrote:

Hi,

On Thu, Aug 22, 2019 at 10:18:44AM -0700, 'Sam Clegg' via emscripten-discuss wrote:
> On Thu, Aug 22, 2019 at 8:01 AM Beuc <be...@beuc.net> wrote:
> > I know about new-asyncify.
> > However I understood Emterpreter wasn't ported to LLVM "yet", but now it seems it won't be at all.
> > (see also https://github.com/emscripten-core/emscripten/issues/9257#issuecomment-523670023 )
> > I'd like to know what the official plan is :)
>
> I think the idea is that asyncify subsumes all the use cases that
> Emterpreter previously did.

It looks like no one knows for sure ;)

I think Sam is right - Asyncify is meant to do everything that Emterpreter (and old Asyncify) used to do. But more efficiently.

The one thing Emterpreter might do better is the Emterpreter bytecode is more compact than JS or wasm, so the total download might have been smaller.

> Is there some use case you have that asyncify doesn't handle?

I had answered you in the link above :)

- debug capacity: Emterpreter provides a detailed stack trace whenever
  trying to pause in the wrong place, which is a must-have to populate
  the WHITELIST in complex code with indirect calls (e.g. Python);
  here AFAICT the ASYNCIFY'd application will just skip the
  emscripten_sleep() and crash mysteriously later.

- pattern-matching in WHITELIST
  (which I had implemented for Emterpreter)

Would be good to get issues filed for those things if there aren't already. (I can try to find time to get to them myself, but not sure when I will be able to.)

In addition, 1.38.42-upstream fails to compile one of my dependencies:
https://github.com/emscripten-core/emscripten/issues/9317
so I cannot do a full-scale test.

More generally, it took me months, lots of reports, lots of patches
and several work-arounds to get Emterpreter stable enough for
RenPyWeb's needs.  Consequently I was hoping to avoid doing that again
and reserve my time for a SDL2 proxy-to-pthread switch/contribution,
should the time come.

> > Good point about MS Chromium Edge.
> > I need to test https://www.microsoftedgeinsider.com/
> >
> > TBH I'd welcome a working SDL2 proxy-to-pthread (even if it worked only for chrome-likes) more than another stack-unwind emulation.

Cheers!
Sylvain

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/20190825212141.exhiwms2cuxdusb3%40mail.beuc.net.

[Beuc]

Hi,

On 26/08/2019 22:09, Alon Zakai wrote:

On Sun, Aug 25, 2019 at 2:21 PM Beuc <be...@beuc.net> wrote:

> Is there some use case you have that asyncify doesn't handle?

I had answered you in the link above :)

- debug capacity: Emterpreter provides a detailed stack trace whenever
  trying to pause in the wrong place, which is a must-have to populate
  the WHITELIST in complex code with indirect calls (e.g. Python);
  here AFAICT the ASYNCIFY'd application will just skip the
  emscripten_sleep() and crash mysteriously later.

- pattern-matching in WHITELIST
  (which I had implemented for Emterpreter)

Would be good to get issues filed for those things if there aren't already. (I can try to find time to get to them myself, but not sure when I will be able to.)

I will when I can test asyncify on my production code. I hit several issues with -upstream that are currently being resolved.

Cheers!
Beuc

[Beuc]

Hi,

Answering myself:

:)

Cheers!
Beuc