Re: [boost] seeking commonalityinfutures/threader/demuxer/defer/etc models

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-12-06 02:27:54

Hi Chris,
> --- simon meiklejohn <simon_at_[hidden]> wrote:
> <snip>
>> As an example, lets say i have a library component that parses
>> data from a socket into some higher level application message.
>> At the time it finds a complete message it wants to notify its
>> client code.
>
> I think this example perfectly illustrates why there is a difference
> between the needs of the caller and callee...

I guess i'm coming from the perspective that casts a
message parsing library as purely a recogniser of
certain kinds of message. As such it is more like
a layer in a protocol stack rather than an application
level 'caller'.

In my analysis (which i dont claim to be universal)
i'd say that the party with the best context for deciding
the dispatcher policy for the parser is the party that
assembles the protocol stack, not the layers themselves.
(and i think that a given recogniser could usefully
be deployed in a range of programs with different
thread archtitectures)

They know what meaning the messages have,
how long it will take to deal with each of them,
how complex the downstream web of receiving objects is,
what else is doing callbacks into those objects
what kinds of thread affinity is required in the recipient objects,
.. all of which have a bearing on choosing a dispatcher.

>
>> - In some applications its appropriate to call immediately in
>> the same thread. (e.g. if the app has only one thread which is
>> blocking in the network layer)
>
> This first case is about the caller, since the caller best knows
> whether it is appropriate to make the call immediately in the same
> thread. E.g. an immediate call might no longer be appropriate if the
> library was changed to use asynchronous I/O so it could handle multiple
> concurrent connections, since blocking on the call would affect the
> service provided to other client code.

Could this be handled by the caller specifying its requirement
for defer/dispatcher through my proposed-but-not-implemented
defer_point categorisations
e.g.
class immediate_defer : public defer_point
{}; // no implementation, just a promise on how defer will happen

class defer_null : public immediate_defer { /* implementation as in sandbox 
*/ };
or also
class defer_mutex : public immediate_defer { /* ditto */};

class parser {
    parser( immediate_defer& dispatcher ) : 
parser_dispatch_(parser_dispatch) {}
    void register_callback(function<void(void)callback);
    ...
    some_method()
     {
        parser_dispatch.defer( callback_ );    // will happen now
    }
}
the developer is then forced to use a dispatcher of appropriate type.
He can decide whether the recipient needs mutex protection or not.

[SNIP]

Splitting this response over a couple of messages, otherwise just
too long

Cheers

Simon