You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
would be very convenient. I see two practical use cases for this feature: It allows us to create constructs similar to Python's generators, where the coroutine iterates over some data structure or computed sequence, and incrementally returns values from it. It also makes it easier to use libaco with event-based frameworks like io_uring, where events have a return value that need to be passed back to the coroutine:
As I understand it, adding a return value would require saving/restoring an additional register. Perhaps this feature could be put behind a #define macro, so that users can choose if they want to take a slight performance hit for this feature.
Right now, this feature can be emulated by using an externally maintained pointer to marshal the data. But this is a very janky design pattern, and I believe that it is best to avoid polluting a codebase with pointers if the necessary data can simply be passed by value.
The text was updated successfully, but these errors were encountered:
Hi Mahdi @mrakh, sorry for the late response. I'm very glad this library is useful to you.
I prefer the usage described below to solve your problem.
// `MyArg` is the struct the co arg is pointing tostructMyArg{
// yieldReason: [sleep, poll_fd, poll_iouring]intyieldReason;
void*yieldRetValue// other members/* ... */
}
// Inside coroutine/* setup MyArg to this co *//* prepare io_uring_task *//* bind this co to the io_uring_task *//* submit io_uring_task *//* MyArg->yieldReason = POLL_IOURING */aco_yield()
ifcheckMyArg->yieldRetValueokhandlethereadyio_uring_taskelsehandletheerror
// inside the schedulerfor{
// scheduler loop// do other stuff...// io_uring stuffio_uring_peek_cqe// nonblock waitingifcoready// resume the ready coaco_resume(co)
end// do other stuff...
}
I think it is better to let the scheduler do the as minimal task as possible, including event polling like fd polling, and io_uring task polling in this case. (I didn't yet dive very deeply into the io_uring, so please correct me if I got a mistake.)
Thanks for this great library!
I think that having something similar to the following functions:
would be very convenient. I see two practical use cases for this feature: It allows us to create constructs similar to Python's generators, where the coroutine iterates over some data structure or computed sequence, and incrementally returns values from it. It also makes it easier to use
libaco
with event-based frameworks likeio_uring
, where events have a return value that need to be passed back to the coroutine:As I understand it, adding a return value would require saving/restoring an additional register. Perhaps this feature could be put behind a
#define
macro, so that users can choose if they want to take a slight performance hit for this feature.Right now, this feature can be emulated by using an externally maintained pointer to marshal the data. But this is a very janky design pattern, and I believe that it is best to avoid polluting a codebase with pointers if the necessary data can simply be passed by value.
The text was updated successfully, but these errors were encountered: