Callbacks in new async std.io interface

Explain
1

I am wondering why the functions of the new interface do not take a callback as a parameter.

In my experiments trying to implement an event loop to work with C++ coroutines based on epoll I would pass a function pointer to resume the coroutine in the call to epoll_ctl(EPOLL_CTL_ADD) that I would later invoke once an event for the file descriptor is returned from epoll_wait.

Abstracting from coroutines, this could be any function pointer to any type of callback. And coroutines are just a convenient way to make the compiler generate callbacks, right?

Zig Showtime #42 (https://youtu.be/l8fDQdSjPQg?feature=shared) shows two kinds of io implementations: blocking and thread pool. In the first case, one could say that a “callback” is invoked by returning from the call to async, whereas in the second case it is by unblocking the thread after await.

What I am trying to imagine is how to emulate coroutines with the new std.io interface, i.e. assuming that i do the state machine transformation myself, how do i hand off operations and continuations/callbacks to the io?

Is the current design viable if one were to forbid the use of multi-threading, green threads, stack switching?

2

Well, the async calls are callbacks.

Specific to your epoll example, the Io implementation handles those details not the caller, this is because not everything works the same, and they don’t want to leak that nuance to the caller, the entire point of an interface.

Less specifically, if you want to do something after your async function ends either:

  • add it to the function or make a wrapper if you’re doing it all the time.
  • do it after you await the result
  • have your function (or a wrapper) itself take a callback.

Can you provide more detail about what you are trying to do/reason about?

this depends on what you are doing, there will always be tasks that have requirements that can’t be filled by all concurrency models/Io implementations.