On 01/21/2014 04:09 PM, Nat Goodspeed wrote:
Niall, would you be able to propose a more universal model? Please read this as a simple invitation rather than a challenge. The goal of
A good place to start is to understand the limitations of the Asio model. The first limitation pertains to chained operations. In Asio you chain operations by initiating the next operation when you receive a callback from the previous operation. Although we can initiate several operations at the same time, these operations are not chained. I am going to ignore scatter I/O here because they have their own limitations (e.g. they either multiple reads or multiple writes, but not combinations thereof.) The second limitation is about multiple types. The Asio model assume that there is a one-to-one correspondence between the type that I request and the type I receive. This is perfectly fine for Asio because it just deals with buffers. However, if you create an asynchronous RPC server using the same kind of callback mechanism as Asio, then you want request a function of any type and receive a function of a specific type. In this design you have multiple "return types" (received function signatures.) It can be useful to put the second limitation into perspective. The RPC example above fits best into the event listener mentioned below. Inspired by a classification by Eric Meijer, we can say that: 1. If we have a single return value of a single type then we use T (or expected<T>) in the sync case and future<T> in the async case. 2. If we have multiple return values of a single type then we use an iterator in the sync case and an observer pattern (e.g. signal2 or Asio callbacks) in the async case. 3. If we have multiple return values of multiple types then we use a variant<T> visitor in the sync case and an event listener in the async case.
the paper seems laudable: accepting an argument that allows the caller to specify whether to provide results with a callback, a future or suspend-and-resume.
Definitely, and it is a significant step forward.