-
Notifications
You must be signed in to change notification settings - Fork 1.6k
add component-model-async/{fused|futures|streams}.wast tests #10106
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
Conversation
7e41099 to
098bd1c
Compare
alexcrichton
left a comment
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.
I think this is as far as I'm gonna get today. I haven't gotten to most of trampoline.rs yet which I realize is most of the guts of this PR, but I'll do that on Monday
alexcrichton
left a comment
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.
Ok I'm trying to decipher trampoline.rs but if it's ok with you I'd prefer to ask for more documentation first before diving further into these methods. Currently there's very little documentation on how things are set up and understanding enough to be able to review this PR I think would require cross-referencing both all the details in the spec along with Wasmtime internal implementation details. A lot of this is also pretty specific to Wasmtime itself in the sense that it's all internal adapter details and we're implementing halves of the spec in some places.
Would you be ok writing up some docs for this? Ideally I'd find it most helpful to have a high-level description of how the adapters piece together and what the expected flow between them is. My hope is that such documentation would also be pretty valuable for future readers to understand this as well.
alexcrichton
left a comment
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.
I'm sorry I know I sound like a broken record but I'm personally still very lost trying to understand this. On one hand one way I can fix this is to go study the component-model specification, try to piece together what an expected implementation would be, and then try to connect those dots back to this implementation. On the other hand though I also think it'd be valuable to have enough local documentation to not require that because although I can do that it would also be required for any future readers as well.
If you feel like I'm requesting too much documentation though or there's something that is well outside the purview of this module's documentation and it's more basic fundamental understanding please let me know though. I don't think we should just mirror the entire specification in comments into this repository, but at the same time I still think there are critical implementation pieces lacking comments such as the protocol between the async-start/return adapters as well as the host-provided async-enter/exit functions.
|
To be clear: I absolutely agree that more docs and comments are needed -- I've only added a bit of that so far but plan to add more. Feel free to ignore this PR until that's done. |
This is another piece of bytecodealliance#9582 which I'm splitting out to make review easier. The fused.wast test exercises fused adapter generation for various flavors of intercomponent async->async, async->sync, and sync->async calls. The futures.wast and streams.wast tests exercise the various intrinsics (e.g. `stream.read`, `future.close_writable`, etc.) involving `future`s and `stream`s. The remaining changes fill in some TODOs to make the tests pass, plus plumbing for a few intrinsics which aren't needed for these tests but which set the foundation for future tests. Signed-off-by: Joel Dice <[email protected]>
|
@alexcrichton I've rebooted this PR based on the latest code in the This PR now includes two more tests ( |
Subscribe to Label Actioncc @fitzgen DetailsThis issue or pull request has been labeled: "fuzzing", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
alexcrichton
left a comment
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.
Thanks for adding these comments!
| vmctx: NonNull<VMOpaqueContext>, | ||
| data: NonNull<u8>, | ||
| ty: u32, | ||
| caller_instance: u32, |
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.
Mind documenting this parameter above? (perhaps documenting that it's currently-unused but soon-to-be-used as well)
|
Thanks for the review, @alexcrichton! I'll address your feedback first thing tomorrow. |
Signed-off-by: Joel Dice <[email protected]>
| /// Import a host built-in function to start a subtask for a sync-lowered | ||
| /// import call to an async-lifted export. | ||
| /// | ||
| /// This call with block until the subtask has produced result(s) via the |
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.
"will block"
| } | ||
|
|
||
| // This closure compiles a function to be exported to the host which host to | ||
| // lift the parameters from the caller and lower them to the callee. |
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.
to be exported to the host which host to lift the parameters ... maybe correct but I didn't know how to parse that part of the sentence.
| i32::try_from(self.types[adapter.lift.ty].results.as_u32()).unwrap(), | ||
| )); | ||
| // Async-lowered imports pass params and receive results via linear | ||
| // memory, and those pointers are in the the first and second params to |
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.
the the
| self.finish() | ||
| } | ||
|
|
||
| /// Compiles a function to be exported to the host which host to lift the |
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.
exported to the host which host to lift ... apologies if this makes sense to folks more in the know, maybe just hard for me to decipher
This is another piece of #9582 which I'm splitting out to make review easier.
The fused.wast test exercises fused adapter generation for various flavors of
intercomponent async->async, async->sync, and sync->async calls.
The futures.wast and streams.wast tests exercise the various intrinsics
(e.g.
stream.read,future.close_writable, etc.) involvingfutures andstreams.The remaining changes fill in some TODOs to make the tests pass, plus plumbing
for a few intrinsics which aren't needed for these tests but which set the
foundation for future tests.