Skip to content

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

Closed
alexcrichton opened this issue Apr 3, 2025 · 3 comments
Closed

Refactoring event codes with respect to recent changes #492

alexcrichton opened this issue Apr 3, 2025 · 3 comments
Labels

Comments

@alexcrichton
Copy link
Collaborator

Currently we have:

class EventCode(IntEnum):
  NONE = 0
  CALL_STARTING = CallState.STARTING
  CALL_STARTED = CallState.STARTED
  CALL_RETURNED = CallState.RETURNED
  STREAM_READ = 5
  STREAM_WRITE = 6
  FUTURE_READ = 7
  FUTURE_WRITE = 8

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 the callback 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 EventCodes 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 single EventCode.SUBTASK. The waitable index to the callback would be the same and the optional code would be the CallState.

@alexcrichton
Copy link
Collaborator Author

Also, to confirm, CALL_STARTING isn't possible, right? That's implicit in the creation of a subtask?

@lukewagner
Copy link
Member

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, CALL_STARTING isn't possible.

@alexcrichton
Copy link
Collaborator Author

Sounds good to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants