Recommended pattern for an event loop implementation with corral coroutines

[abdes]

I may be missing something obvious, so I apologize in advance if that's the case. I failed to see any of the existing examples or test cases that models an async generator that yields values in a repetitive way. The corral promise does not have a yield_value method, and co_yield is only used as a trick for the nursery implementation.

The scenario is an event source running in a loop. It is different from the corral Event which only happens once and cannot be undone (by default, unless it recreated of course).

1. What is the recommended pattern in corral to consume such "event" stream from a task?
2. What is the recommended pattern when multiple tasks are interested in the events produced by that event source? Note here that Shared solves the problem of multipls tasks awaiting an async value, but assumes that happens only once.

[oremanj]

corral doesn't currently ship with syntactic support for async generators, but async generators are logically just tasks with an ambient output stream for values. You can make an explicit stream for values using corral::Channel. This isn't quite the same as an async generator because there is a buffer - the sender and receiver can be operating at the same time. But it should work fine for an event stream. Instead of writing a loop for the sender to iterate over the receiver, you would start the sender and receiver as separate tasks joined with allOf() or similar.

What is the recommended pattern when multiple tasks are interested in the events produced by that event source?

If you want any single task to get each object sent through the channel, you can just have all the tasks simultaneously await channel.receive(). If you want each task to get each object, you can have one channel per receiver and let the sender (or another proxying task) write to all of them.

[abdes]

Regarding co_yield, just curious to know if you consider it a "useless" thing in coroutines, or if you just did not have the need for it so far. Your perspective would be appreciated.

For the second point, I actually did some tests using two implementation options:

1. A channel per receiver, and the sender task writing the event object to each channel, and 4 tasks awaiting the event.
2. A pair of Shared objects, paired with a Semaphore. One shared is used to await, while the other is being processed by the receivers. This allows a task that completes quickly on an event, to immediately wait again for the next event on the shared that has been re-created for waiting. The semaphore is used by the receivers and the event pump to ensure no new event is pumped until all receivers on the previous event have been scheduled. When a receiver is resumed, it locks the semaphore while it is doing things.

I run some benchmarks, and the result is actually comparable between both methods, although the first one, with buffering inside each channel can allow receivers to process events at different speeds, while the second one enforces one single event is in-flight at any time. There is a slight degradation of the performance of multi-channel as the number of receivers goes up (as expected).

benchmark name                       samples       iterations    est run time
                                     mean          low mean      high mean
                                     std dev       low std dev   high std dev
-------------------------------------------------------------------------------
DoSomething                                    100             1    205.314 ms
                                        2.02772 ms    2.00078 ms    2.06871 ms
                                        167.215 us    120.748 us    223.273 us
-------------------------------------------------------------------------------
synchronized shared                            100             1     3.31996 m
                                          1.489 us      1.355 us      2.107 us
                                        1.25427 us     107.42 ns    2.97838 us

multi-channel                                  100             1      3.3245 m
                                          1.569 us      1.388 us       2.09 us
                                        1.38043 us    250.567 ns    2.93604 us

DoSomething() is something that one of the 4 receivers does and takes longer time than what the other receivers do.

By the way, to give you more context why I'm doing this, I'm experimenting with implementing a game loop and the underlying frame rendering process using coroutines. A lot of this micro-tasks traditionally run within a certain amount of time, and are sequenced via the game loop micro-managing them. With coroutines, the model is completely changed: we just fire and forget tasks and event handlers in nurseries and let the very simple Event Loop run the game. Just experimenting, but so far the effect on the code clarity and the design of the game engine is positive.

[oremanj]

We haven't needed co_yield so far / found it worthwhile. It's not useless, but it's mostly a notational convenience from the user side, and on the implementer side it requires a whole different promise type for async generators. The promise type is one of the most subtle/complex parts of corral and maintaining two of them is worse than maintaining one. Like, look at corral/detail/Promise.h, then look at your favorite C++ stdlib's implementation of std::generator, then imagine mashing them together -- it's not a pleasant thought! We haven't really tried though; there might be some way to be clever about the implementation that would keep the marginal cost minimal.

Async generators are also more restrictive than tasks-with-channels - you can't yield a value while the generator has started anything in the background, because that would violate the structured concurrency invariants (failures in those background tasks have nowhere to propagate to while the generator is suspended). Some larger-scale users of Trio have adopted a Just Say No policy on async generators. They're a cool idea but the details can get rather devilish.

[abdes]

Makes sense. Haha... By the way, I looked at other implementations, and their code is difficult to read compared to corral or lacks the features and predictability of corral😄.

I have worked around the lack of co_yield by using a Channel or by simply recreating the awaitable such as Shared or Event every time it completes. I found that the pattern used in ParkingLot where we do co_await lot.Park() is nice and decouples the waiting tasks from the awaitable through that indirection: co_await obj.TheNextThing();.

Thanks a lot for the feedback!