Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-01-22 19:26:30

On 23/01/2014 06:37, Quoth Bjorn Reese:
> 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.)

I'm having trouble understanding this.  A chained operation must by 
definition be one operation being called as some other operation 
completes, and can never possibly refer to operations running in parallel.

You can certainly have multiple operations related in fashions other 
than chains, either by giving them the same callback target object, or 
by calling them through the same strand, or by calling them on some 
object that has some internal policy about how concurrent operations are 
managed, or by making a new composite operation that internally manages 
sub-operations in a fashion invisible to the caller.

> 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.)

Or each "function" is just a custom async operation.  You don't request 
a function and then try to interrogate it, you just execute operations.

It's pretty easy to define new I/O objects in the ASIO model and give 
them whatever async functionality you want.

Granted, it's all in-process, so you'd have the added complication of 
injecting some sort of serialisation and remoting to make it RPC, but 
it's still fairly readily achievable, I think.