Structured Concurrency
ericniebler.com
ericniebler.com
That's the easy part and typically not entirely what you want. Suppose you have some fibers you launched via a parmap. Most of these will end more or less at the same time, but some will be laggards and these need to be tracked in some way. That tracking typically happens outside of your current lexical scope as they might not influence the success of the composed fiber.
[0] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
When you make a async operation there are two things: the operation itself, e.g. read/write and the timer associated with that operation (you really don't want infinite timeouts in production code).
Both need information about the async operation in their respective handlers. You can't do composed operations (std::move(this)) since one of the read/write or timer handlers will be given a moved-from object.
The only wasy I can see to solve this is through the use of a ringbuffer and using indexes into this ringbuffer as a 'handle' to the async op (see LMAX's Disruptor). It saves from needing shared_ptr / enable_shared_from_this. You're going to need a bounded queue anyway to prevent a fast producer from causing OOM.
Feels like C++ is catching up…
[1] https://wiki.openjdk.java.net/display/loom/Structured+Concur...
http://man.postnix.pw/9front/2/thread
example code (random 9 mirror I picked): https://github.com/mischief/9problems/blob/master/sys/src/li...
I always feel a bit sad when I see that other programming languages try to solve the same problem and come up with an inferior solution that they then try improve by fixing edge cases. I wish programming language authors would learn more from each other.