Allow async function to be imported/exported

[eduardomourar]

There are certain cases where the host/guest implementation needs to pass an asynchronous function. Can this be supported in the JavaScript codegen even when the WIT definition has its signature as synchronous?

[guybedford]

It is up to the implementation to ensure it provides a sync API. In Node.js it is always possible to syncify any call though on the implementaiton side by creating a worker thread and using atomics to synchronously wait on a shared lock in the worker that is performing asynchronous work. Usually it's best to just have a fully sync implementation though.

[DougAnderson444]

Have you guys seen the work Joel Dice did here: https://github.com/dicej/isyswasfa/tree/main

It's very experimental at this point and only in Rust, but looks like it will be very useful when he gets to JavaScript.

[guybedford]

Yes, we will follow in this path in the Jco project, where functions may support both sync and async variants depending on the canon ABI option passed. Preview 3 support is a little way off though still.

If anyone is interested in prototyping in the mean time along a similar lines, work here would be welcome.

[DougAnderson444]

linking here for reference: dicej/isyswasfa#1 (comment)

[vados-cosmonic]

Hey @eduardomourar with the merge of experimental JSPI integration this should be possible in jco with NodeJS, and as far as the work to support Async components is concerned (which is similar, but different) that will be covered by #617 (It's been a while but heads up @DougAnderson444 if you're still interested!)

As extra context, see #551 which contains some pieces of an alternate approach (asyncify), and updates to the browser bindings. We hope to get the experimental browser-side bindings updated but there's not a great timeline just yet on when that PR will be reformulated/can be finished (if it will even make sense, given growing support for JSPI).

I'll close this issue for now -- please feel free to comment if you think it should be re-opened.

[James-Mart]

@vados-cosmonic

not a great timeline just yet on when that PR will be reformulated/can be finished (if it will even make sense, given growing support for JSPI).

My concern is that JSPI is brand new and still not supported in major browsers (For Safari I can't even find a timeline).

Given that, I guess sync-ifying browser bindings in a device-compatible way is still possible if the component developer can handle the heavy-ish lift of manually asyncifying their component post jco-transpilation? Anyone know of a guide on this?

[calvinrp]

@James-Mart It is possible to use Asyncify, but there's a bit involved to wire up the jco transpile generated code to make it work. I had a PR that is mostly done that is still planned. Is that what you are after?

[James-Mart]

Is that what you are after?

Yeah, ultimately that's what I'm after, because I feel like I can't depend on JSPI until it's more widely adopted by browsers. But if your PR is deprioritized, then the next-best thing for me would be some guidance on how I can manually asyncify some of the browser bindings in my components (presumably after transpilation).

[calvinrp]

@James-Mart I'd still like to get the PR for Asyncify support into jco. But I'm not sure when I can get to it. Maybe in a few weeks. I would not recommend to manually modify the jco transpiled output. It is tricky to do correctly. How urgent is your use case?

[James-Mart]

I would not recommend to manually modify the jco transpiled output

Hmm, okay.

It's not super urgent, but I've definitely got a growing backlog of items that are blocked until I have this capability 😅, so the sooner the better on my end.

Probably 2-3 more months before I will need to start seriously considering finding an alternative or reworking the architecture more broadly.