RE: [boost] Re: [Threads] Reactive Objects

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())
> {
>   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 ;-)