Boost logo

Boost :

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

> 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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at