auto curried_async_foo(params_t params) {
return [params](invokable<result_t> cont) {
async_foo(params, cont);
};}
...
auto op = curried_async_foo(params);
op(receiver);
- finally modify the curried variant to add another required evaluation round:
auto foo_sender(param_t params) {
return [params](invokable<result_t> cont) {
return [params, cont]{
async_foo(params, cont);
};};}
...
auto sender = foo_sender(params);
auto operation = sender(receiver);
operation();
The actual library uses structures with named methods instead of callables (so you would do operation.start() for example), plus a separate continuation for the error path (by having the receiver concept implement two named functions), and cancellation support. Also the final operation is required to be address stable until it is completed.
The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).
The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.
The essence of the sender/receiver proposal is essentially this: - first start with a sync function
- make it async by adding a continuation: - then curry it: - finally modify the curried variant to add another required evaluation round: The actual library uses structures with named methods instead of callables (so you would do operation.start() for example), plus a separate continuation for the error path (by having the receiver concept implement two named functions), and cancellation support. Also the final operation is required to be address stable until it is completed.The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).
The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.