From: scott (scottw_at_[hidden])
Date: 2004-03-03 19:04:07
> [mailto:boost-bounces_at_[hidden]]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())
> 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?
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
I leave those notes in, due to bloody-minded sense of
> 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.
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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk