Meeting 24 October 2019

2019-10 Pre-Belfast Mailing

https://www.reddit.com/r/cpp/comments/dhm138/wg21_the_201910_mailing_is_now_available/

Eric Niebler on Executors

Corentin: Executors are the least useful part of "A Unified Executors Proposal"

It makes me happy to see the power of the Scheduler/Sender/Receiver recognized.

Much of traditional Rx assumes runtime polymorphism and garbage collection / ref counting. That's obviously a poor fit for C++. The sender/receiver design skews toward static polymorphism w/Generic interfaces, and explicit memory mgmt.

The factoring of submit into connect/start gives more flexible ownership semantics, and aligns the design conceptually with coroutines, making coroutines an efficient way of expressing sender/receiver.

Once you introduce concurrency with non-overlapping scopes, the lifetime of your async operation state no longer corresponds to a simple C++ scope. That's why explicit memory mgmt and ownership become issues where they wouldn't be otherwise.

One of coroutines great strengths is that they let us map async lifetime back to C++ scopes. Under the hood, the coroutine is carved up into callbacks, and the operation state (coroutine frame) is getting managed explicitly, but all that gets hidden from you by the coro types.

Sender/receiver is a library reification of this separation. You might argue (and some have) that we should just drop sender/receiver and use coroutines everywhere for everything "async". That's appealing, but goes too far. Coroutines, for all their value, come up short sometimes.

C++ has a long sad history of giving old things new names. Map and fold would have been better than transform and accumulate, and don't get me started on vector. Sender/receiver share some pedigree with Observable/Observer, but they really are different beasts ... by necessity.

The intended purpose of sender/receiver is to be a base lingua franca for all C++ async libraries. I expect end-users to interface at much higher levels of abstraction in their own code.