Ingvar Stepanyan

Unifying `PROXY_TO_PTHREAD` + Asyncify via single API for the user is something I also thought about in the past, and would love to see it happen someday, but it's clear...

> IIRC, at least for the web, any api that is async would need to do async work and need to return the event loop no matter what, so it...

> Is it easy to detect "an exported method is using Asyncify ".. what does that mean exactly? I mean purely at runtime. We already have codepaths for old Asyncify...

E.g. here is the codepath for Embind: https://github.com/emscripten-core/emscripten/blob/a0a3f24b17a308791d417831d060a46b54f15fbd/src/embind/embind.js#L861-L863 There are couple more places that will need updating, but should be a pretty straightforward change, just needs someone to do it.

> I think we should probably first decide if we want asyncify and JSPI to behave the same or if we're fine with them being different. > A warning does...

I thought it was hard requirement of JSPI?

Ah I see. > I think with asyncify it was more common that the user would just run a main program so they wouldn't really need to worry about what...

Hm doubling exports is an interesting alternative I guess, although a bit unfortunate. For now all I want is some sort of consistency between the two versions/features, but if it's...

> It's been when code assumes a sync value and then the promise gets passed back into wasm and auto stringified and converted to a number and silently goes on....

> If it's too early to show a warning like in the initial description of the issue, then at the very least, the new explicit markers should be just ignored...