Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-02-09 19:20:42

On 9/02/2014 02:14, Quoth Bjorn Reese:
> As we are exploring the limitations of the Asio model, I would say that
> the mode can change in any imaginable manner: it could alternate between
> two modes on each request, or it could change only a subset of the
> requests rather than all, just to name two. And this would be completely
> transparent to the client, because it the general case it is not simply
> a matter of accepting or rejecting requests, but about processing them
> differently.

I still think you're imagining a scenario that doesn't make sense in 
practice.

> So I guess that it boils down to:
>
>    1. Can I replace a continuation after the function has been
>       initiated?

You have to have something that is holding the continuation so that it 
can be called later.  There's no reason *in principle* why this cannot 
be handed from one object to another as desired as long as the 
conceptual operation is still in progress as far as the caller is 
concerned.  (In fact, this actually happens in ASIO -- a pending 
operation is held by the I/O object until it completes, then is passed 
to the generic scheduler to execute the user handler.)

If something significant happens that the caller is likely to want to 
know about (such as changing license state etc), then it may be 
worthwhile cancelling the connection (by calling back with an error 
code) and getting the client to reconnect, because it might want to set 
up a different set of pending operations / subscriptions given the new 
state.

When there are multiple pending operations, there's no reason why you 
can't cancel some, initiate others, and leave the rest going (depending 
on what makes sense for the particular change in question).

(I said "in principle" above because the current ASIO model makes heavy 
use of templates for performance and to enable auxiliary features such 
as strands and custom allocation; the way that it's implemented at the 
moment these can't survive a type-erasure boundary such as would be 
required to pass through an RPC system.  Instead you'd have to replicate 
these on each side -- but you'd probably want that anyway.)

>    2. Can I group several of such replacements so that they will be
>       replaced at the same time (or at least before the next event
>       occurs)?

In the context of "a thing that implements ASIO-like callbacks", sure. 
As I said above, you'd just have to move the list of pending operations 
from one implementation to the other, and the caller wouldn't know the 
difference as long as whatever handle it uses to make async requests is 
still valid.  (Things get hairier if you're processing events on 
multiple threads, though.)

In the context of ASIO specifically, not really, at least not once the 
operations have been marked as complete and ready to execute.  But I'm 
still not really sure why you'd want to.