Hi Chris,
--- simon meiklejohn <simon@simonmeiklejohn.com> 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