Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Bjorn Reese (breese_at_[hidden])
Date: 2014-01-31 04:28:39

On 01/27/2014 11:16 PM, Gavin Lambert wrote:

> You flip it around.  Instead of having an event listener object that is
> registered on some event provider source, where the provider source
> invokes the methods explicitly when an event arrives, you have anything
> that is interested in events invoke an async request on the source
> object.  So it'd be something more like this:
>
> class gui_source {
> public:
>     // actually using templates to make the callback more generic
>     void async_key(void (*callback)(error_code ec, int key));
>     void async_help(void (*callback)(error_code ec, int x, int y));
> };
>
> The code on the receiving side just handles a callback instead of
> receiving an explicit call, but otherwise it's basically the same.

This is an intesting idea. Although it does involve a lot of plumbing,
I agree that it can be done.

As we are exploring the limitations of the Asio model, let me introduce
a use case that is difficult to do within this kind of parallel
initiator-callback paradigm.

Consider a secure RPC server, whose full API only can be used if the
client has the correct privileges. For simplicity, let us assume that
this is a single-client server. There are two modes: unauthenticated
and authenticated. In unauthenticated mode, the server should reject all
but the authentication requests. The way you typically would do this is
to have separate implementations of the API for each mode, and when the
client has been authenticated, the server will switch from the
unauthenticated to the authenticated implementation. This wholesale
replacement of the underlying implementation is much more difficult
to do with the parallel initiator-callback style. We could solve the
problem with another level of indirection, but that would effectively
re-introduce the event listener.