hnes / libaco

A blazing fast and lightweight C asymmetric coroutine library 💎 ⛅🚀⛅🌞
https://libaco.org
Apache License 2.0
3.49k stars 392 forks source link

Feature request: Ability to return a value from aco_yield() #47

Open mrakh opened 2 years ago

mrakh commented 2 years ago

Thanks for this great library!

I think that having something similar to the following functions:

void* aco_yield_value();
void aco_resume_value(aco_t* aco, void* val);

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:

// Inside coroutine...
struct io_uring_sqe* sqe;
int amt_read;
char buf[1024];
int fd;
// ...
sqe = io_uring_get_sqe(ring);
io_uring_prep_read(sqe, fd, buf, sizeof(buf), 0);
io_uring_sqe_set_data(sqe, aco_get_co());
io_uring_submit(ring);
amt_read = (int) (intptr_t) aco_yield_value();
// ...

// Inside event loop...
struct io_uring_cqe* cqe;
aco_t* coro;
int result_val;
// ...
io_uring_wait_cqe(ring, &cqe);
coro = io_uring_cqe_get_data(cqe);
result_val = cqe->res;
io_uring_cqe_seen(ring, cqe);
aco_resume_value(coro, (void*) (intptr_t) result_val);

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.

hnes commented 2 years ago

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 to
struct MyArg{
    // yieldReason: [sleep, poll_fd, poll_iouring]
    int yieldReason;
    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()
if check MyArg->yieldRetValue ok 
   handle the ready io_uring_task
else
   handle the error
// inside the scheduler
for{
    // scheduler loop
    // do other stuff...
    // io_uring stuff
    io_uring_peek_cqe // nonblock waiting
    if co ready
        // resume the ready co
        aco_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.)