Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Bjorn Reese (breese_at_[hidden])
Date: 2014-01-22 12:37:31

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.