[mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt
themselves. Is it
to be "method-based" or "message-based"? I can see that your baby will sing but so does messaging.
Method-based can be layered above messages, if the messages support the concept of having their dispatch addresses potentially pre-bound.
Yes. Nice acknowledgement of what has been staring us in the face.
The scheduler of the message-driven system can do something like:
message m = dequeue(); if (m.dispatch_bound()) { m.dispatch(); } else { servant->dispatch(m); }
where the unbound case calls a function that switches based on the message code or content.
Understand why you present this code and can see that it will deliver. Here is a question though; if we acknowledge that we are sending messages at a moment when we know what "method" we wish to call (terminology chosen for your benefit :-), couldnt we decide to send specific messages? By this I mean a different C++ type for each "method". If we also said that the callback always had the same name (e.g. process_message) then - do we not have enough to perform some compile-time dispatch trickery? struct db_open { }; struct db_select { }; .. my_db_server::process_message( db_select & ) { } Using some (pretty low-order) template trickery I think it would also be possible to default to a sane member in the event that the target machine did not declare the member with a matching signature; my_db_server::process_message( unknown_message ) { } I think the queue of messages would remain the same - type independent. Selection of the member pointer would just be happening automatically, through overloading, at the call site. I suggest this warily. It breaks the design goal I had with previous work and precludes implementation of some of the "edgy-er" active objects already discussed. But it seems damn nice if we have no such targets? To further scuttle my own suggestion :-( anything along these lines would require the sender knowing the complete type of the receiver. A design constraint I find truly distasteful. I leave those notes in, due to bloody-minded sense of completeness.
Then all the proxies need to do to yield a method-based interface is bind the address into the message before queueing.
Read and re-read this cos I was determined to not be suggesting something that you already had :-) My best guess is that I have introduced a third form of dispatch, where m.dispatch_bound() would evaluate true?
If we can agree on something here then we would have a complete target for something built on boost.thread, i.e. there are no other "areas"?
I think messaging between thread contexts is a useful target.
Wonderful. I think I might knock out a list of requirements next. Something to drive a first draft implementation. I can post this if you are interested. Cheers, Scott ps: Thoughts I have for the implementation are currently the combination of your work and Mark's. It doesnt bother me who tackles what, if anything. I will plod the long and winding road ;-)