Writing Senders -- Lucian Radu Teodorescu
In the December issue of Overload [Teodorescu24], we provided a gentle introduction to senders/receivers, arguing that it is easy to write programs with senders/receivers. Then, in the February issue [Teodorescu25a], we had an article that walked the reader through some examples showing how senders/receivers can be used to introduce concurrency in an application. Both of these articles focused on the end users of senders/receivers. This article focuses on the implementer’s side: what does it take to implement senders?
Writing Senders
by Lucian Radu Teodorescu
From the article:
If people are just using frameworks based on
std::execution
, they mainly need to care about senders and schedulers. These are user-facing concepts. However, if people want to implement sender-ready abstractions, they also need to consider receivers and operation states – these are implementer-side concepts. As this article mainly focuses on the implementation of sender abstractions, we need to discuss these two concepts in more detail.A receiver is defined in P2300 as “a callback that supports more than one channel” [P2300R10]. The proposal defines a concept for a receiver, unsurprisingly called
receiver
. To model this concept, a type needs to meet the following conditions:
- It must be movable and copyable.
- It must have an inner type alias named
receiver_concept
that is equal toreceiver_t
(or a derived type).std::execution::get_env()
must be callable on an object of this type (to retrieve the environment of the receiver).A receiver is the object that receives the sender’s completion signal, i.e., one of
set_value()
,set_error()
, orset_stopped()
. As explained in the December 2024 issue [Teodorescu24], a sender may have different value completion types and different error completion types. For example, the same sender might sometimes complete withset_value(int, int)
, sometimes withset_value(double)
, sometimes withset_error(std::exception_ptr)
, sometimes withset_error(std::error_code)
, and sometimes withset_stopped()
. This implies that a receiver must also be able to accept multiple types of completion signals.The need for completion signatures is not directly visible in the
receiver
concept. There is another concept that the P2300 proposal defines, which includes the completion signatures for a receiver:receiver_of<Completions>
. A type models this concept if it also models thereceiver
concept and provides functions to handle the completions indicated byCompletions
. More details on how these completions look will be covered in the example sections.