-
Notifications
You must be signed in to change notification settings - Fork 89
Refactoring event codes with respect to recent changes #492
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
Labels
Comments
Also, to confirm, |
That's a good idea; makes sense to me. There's already a pending breaking ABI tweak for #490, so we could include this change to minimize the number of such breaks, if that makes sense? And you're right, |
Sounds good to me! |
lukewagner
added a commit
that referenced
this issue
Apr 10, 2025
lukewagner
added a commit
that referenced
this issue
Apr 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we have:
Additionally the callback for async lifted exports receives three 32-bit integers at this time: an
EventCode
, an optional waitable index, and an optional code for the event.With futures/streams there's currently a nice property that for any waitable there's a single
EventCode
that corresponds to it, for example the two reads of a stream/future have a read/write event. Additionally the optional code to thecallback
exactly corresponds to what the read/write/cancel intrinsics all return.For subtasks, however, the three events a subtask can receive are split across different
EventCode
s where the optional code for each event is always zero.How about refactoring these codes/states with respect to the upcoming change of two-handle streams/futures? The idea would be to fold
CALL_*
into a singleEventCode.SUBTASK
. The waitable index to thecallback
would be the same and the optional code would be theCallState
.The text was updated successfully, but these errors were encountered: