-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRAFT: Adding JSPI and Asyncify #518
base: main
Are you sure you want to change the base?
Conversation
7310483
to
c78df30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very exciting to see this, thank you.
Left some initial comments.
record async-imports-exports { | ||
imports: list<string>, | ||
exports: list<string>, | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since components can contain multiple sub-components, this is currently joining imports and exports across all sub-components.
If we only consider the outer component import and exports, then we should restrict to that, but we can't do that either since internal components must be async if the outer component is!
Therefore I think we should probably restrict this to outer component imports only
And we should make exports all async as soon as we go into asyncify mode. This also will then help avoid the easy footgun of inadvertantly not making an export async, and then finding it calls an async import down the line which would trap.
const DEFAULT_ASYNC_IMPORTS = [ | ||
"wasi:io/poll#poll", | ||
"wasi:io/poll#[method]pollable.block", | ||
"wasi:io/streams#[method]input-stream.blocking-read", | ||
"wasi:io/streams#[method]input-stream.blocking-skip", | ||
"wasi:io/streams#[method]output-stream.blocking-flush", | ||
"wasi:io/streams#[method]output-stream.blocking-write-and-flush", | ||
"wasi:io/streams#[method]output-stream.blocking-write-zeroes-and-flush", | ||
"wasi:io/streams#[method]output-stream.blocking-splice", | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be nice to automatically include a preview2 implementation designed for async now, and run the preview2 tests against that.
One issue here is how to get the async imports, but an easy option might be to just use a convention like:
import ... from '@bytecodealliance/preview2-shims/async/io'`;
This would be amazing to explore further...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I have a working draft of WASI P2 shims that I have been testing against. But was thinking of breaking into a separate PR.
…ESM imports when using `--instantion`
Adds options to
jco transpile
andjco types
:Which treats the specified imports and exports as
async
using eitherJSPI
orAsyncify
.JSPI is behind a feature flag in Chrome, Deno and NodeJS. Can run via:
DENO_V8_FLAGS="--experimental-wasm-jspi" deno
From my understanding,
Asyncify
does not support reentrancy (so it throws an error) but JSPI does.