RE: [boost] Re: [Threads] Simple active object wrapper, take 2

From: scott (scottw_at_[hidden])
Date: 2004-03-03 20:59:50

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Darryl Green
> Sent: Wednesday, March 03, 2004 11:38 PM

> I've tended to think of the tightly/early bound, just queue a functor,
> and the message passsing + switch case as 2 completely independent
> patterns, but maybe they should be built on a common framework (at a
> level above the detail that they both ivolve queuing some sort of
> object).

Yes. I agree with your distinguishing of the two forms. There is some
relief to be found in that.

While I can acknowledge the existence of async messaging where the
sender has type knowledge of the receiver, I also think its dangerous.
Given the two approaches, most developers head down the "fake method"
route. This inevitably results in receipient-type knowledge and that
precludes some really cool active objects (please refer to other
messages if this fails to allude to anything). Also I think its right
to say that there is nothing method-based that cant be done message-
based; but is the converse true?

There is some more fundamental reason why message-based is right that
is probably rooted in theory (sets?). There has to be good reason why
protocols are so "right". Everyone appreciates the content of RFCs and
telephony signaling specifications but we persist with method-based
messaging.

<sigh> Its an area of personal wonder.

> The AO pattern doesn't require that you identify the object 
> you want to
> invoke the method on in the proxy, because you send the proxy to that
> object, and only that object. So one could drop the "this" parameter
> from the proxy. That would potentially allow the proxy to be
> routed/forwarded in a more general reactive object model (I think this
> was one of Scotts requirements)? I'm not 100% sure how useful this is,
> but it might be nice for the class of problem where you do want
> concurrent execution - of as many completely independent instances of
> the object as is "useful". The client/master doesn't care 
> which instance
> - the next available one will do nicely.

IIUC, this is a de-generate form of interaction that has been touched
on previously. At least in my work it imposes an unacceptable design
constraint;
there needs to be some identification of the receiving active object.
Most significantly (?) there could not be multiple servants per scheduler
(i.e. thread).

> is. Perhaps its interface can be made more generic to allow its
> operation to be policy based. Broadening the definition from "return
> value" to "message delivery notification" with the sender supplied
> message delivery notifier object passed the return value from the
> handler doesn't feel too weird to include at the low level, and
> shouldn't cost anything for a void return without notification.
> Interestingly, the option to generate a a notification that a message
> with a handler returning void has been processed doesn't seem like a
> strange feature when looked at this way (a void future is a bit odd
> though).

Followed everything up to the point where you start discussing "return
values". On one hand you do discuss this as simply another message. OTOH
you do persist with some method-based concepts. Maybe this is not
significant.

> This observer didn't see the state machine aspect as the 
> exclusive use,
> more an important use case reflected in the design. Would that be fair
> to say?

Absolutely.

> My questions that I've been thinking out loud about (always 
> dangerous in
> public) were:
> What is a message? What is acceptance? 

Yes, essential questions :-)

Respondez du jour? A message is an object that is self-discriminating
(within the world of known messages) and carries associated parameters.
It is always a member of a family, i.e. a protocol. A protocol and
its messages is defined independent of all active objects.

Acceptance I'm not so sure of. The word carries a sense of righteousness
whereas the worst that active objects seem to do is discard. Protocols
may include messages along the lines of "that last message was so, like;
wrong" but then that exchange would itself be defined in the protocol.

Maybe messages are simply processed. Or consumed. What a wimp-out.

> Sorry this was so long - am I barking up the wrong tree here or not?
> 

Its so hard to be sure. I've got my wrong tree - you find your own :-)