add stream.forward and future.forward builtins (alternative definition) - #717
add stream.forward and future.forward builtins (alternative definition)#717lukewagner wants to merge 2 commits into
stream.forward and future.forward builtins (alternative definition)#717Conversation
rvolosatovs
left a comment
rvolosatovs
left a comment
There was a problem hiding this comment.
I think this looks good overall, however it appears that with this refactoring the Python host loses a way to specify a custom host-provided cancel and so "true" async cancellation does not appear to be possible anymore. In other words, it seems like cancel_copy can never return BLOCKED anymore.
I'm not entirely sure whether the Python host implementation in this repo is meant to be "normative" or not, but if it is, then this should probably be addressed
| The [Stream State] and [Future State] sections describe the runtime state | ||
| maintained for streams and futures by the Canonical ABI. | ||
| Given the readable end of one stream/future and the writable end of another, the | ||
| `{stream,future}.forward` built-ins can be called to efficiently forward all |
There was a problem hiding this comment.
Shouldn't this be gated by the forward emoji?
There was a problem hiding this comment.
In Concurrency.md, since it's high-level and not listing the individual grammar rules or opcodes, I haven't been finely emoji-gating; if you follow the links though you see the emoji-gate on the built-ins.
|
I split out the refactoring commit into #719 which, incidentally, @rvolosatovs now addresses your comment by explicitly modelling the host blocking cancellation. With #719, the still-rather-short definition of |
Co-authored-by: Roman Volosatovs <rvolosatovs@riseup.net>
2 participants
This PR is based on the great work in #709, but reformulates the definition of
{stream,future}.forwardto avoid the dynamicforwardfield/indirection on streams/futures that was a bit invasive and complex to think through. Instead the definition in this PR mutates the relevant readable and writable ends in-place which ends up being a lot simpler and, iiuc, closer to what an implementation would actually do. To enable this "just mutate the ends" approach in the second commit, the first commit refactors the definition of streams/futures so that streams/futures always have ends (even when the host is the reader and/or writer). This refactoring was a bit invasive, so it felt bigger than something I could reasonably ask for in a review comment in #709. But it ended up becoming a pretty nice simplification for futures/streams overall that reduced lines of code, removed some special cases, and highlighted a spec bug whereDROPPEDwasn't delivered as eagerly as it should have been (included as a WAST test in the refactoring commit that Wasmtime passes).The only actual behavioral difference in this PR vs. #709 that I'm aware of is that there is no trap in the "self-loop" corner case (where the readable and writable ends passed to
{stream,future}.forwardare both attached to the same stream/future); it's just a no-op (the stream/future is no longer alive since both of its ends were just dropped). But if anyone has any good reasons why it should trap, happy to discuss.The refactoring/simplification commit is nice, but touches a lot, so if you're only interested in
{stream,future}.forward, I'd suggest only looking at the second commit. The second commit also includes a bunch of WAST tests for the various interesting semantic cases.PTAL @rvolosatovs