FW: [boost] Re: Re: Future of threads (III)

From: scott (scottw_at_[hidden])
Date: 2004-02-16 22:49:36

forwarding to boost on the assumption that it
was your intention. apologies if i got that
wrong.

-----Original Message-----
From: scott [mailto:scottw_at_[hidden]]
Sent: Tuesday, February 17, 2004 4:42 PM
To: 'Jody Hagins'
Subject: RE: [boost] Re: Re: Future of threads (III)

> -----Original Message-----
> From: Jody Hagins [mailto:jody-boost-011304_at_[hidden]]
> 
> 
> The "typical" (i.e., most commonly implemented) method is to use a
> thread-safe message queue, coupled with a condition variable.  While
> there are messages to be processed, the "active object" pulls 
> them from
> the messages queue, and responds appropriately (the AO 
> specific logic). 
> When there are no messages available, the AO sits on the condition
> variable, awaiting an indication of the arrival of a new 
> message.  I am
> sure you understand this, but I could not figure out any other
> interpretation of your question...

I was responding to your mentioning of the "future" mechanism. Its
a perfectly valid mechanism but I was trying to build a case for
an implementation of boost::active_object that would never use
it.

> > I suggest that notions of "function call" should be exorcised from
> > discussions that are targeting active objects. That type of thinking
> > is perfectly valid in some other thread (oops) but can scuttle work
> > targeting active objects; the behaviour (i.e. the code) is 
> inherently
> > in the object.
> > 
> > a client can only submit "worker orders" or "Method Requests" or
> > jobs or messages or signals.
> > 
> > I hope there is enough there to make a case :-)
> 
> 
> I think what you are saying is right in line with traditional methods
> for implementing an AO, but I thought we were trying to find alternate
> methods, unless I mistakenly misinterpreted the preceeding
> communications.
> 

Well, I've learnt to not take anything I send too seriously. These
days I am happy if I get the spelling right.

I can imagine that there are many approaches to application
of the ActiveObject pattern. What I am trying to do so badly is
steer discussions away from certain directions. Technically they
may be completely justifiable. Strangely I have seen well intentioned
implementations of AOs go down some of these paths and the result
is not what anyone wants. And nobody really knows where it wandered
off target.

Personally I believe that what people (developers) _really_ want is the
ability to conveniently right a bunch of code fragments that are
executed in response to some event (e.g. reception of a message).
The collecton of fragments is "the active object". We want the
environment to take care of all the nasties such as multi-threading,
temporary storage of messages (queueing), routing of message to
code fragment and calling of code (passing parameters from message).

I think the most insidious error in previous developments has been
the assumption of an equivalence between the message sent and a
specific function call. Once this assumption is tossed out, implementation
becomes more sane and the result is what was targeted. Or closer
anyhow :-)

The collection of code fragments is the active object. The collection
of messages exchanged is a protocol. Until these concepts are to the
fore (rather than synchronous, procedural type concepts) then
any implementation of boost::active_object will tread the path
that others have.

actually i have no doubt it would result in something amazing; just
not what i was hoping for in an active object :-)

> Drinking is not a spectator sport.

Cin cin,
Scott