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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2004-02-16 22:02:48

On Tue, 17 Feb 2004 15:27:21 +1300
"scott" <scottw_at_[hidden]> wrote:

> While I understand its place in the ActiveObject pattern I would hope
> that if a boost::active_object came into existence, there would be a
> single (i.e. not _simple_) mechanism by which data passed from one
> thread to the other, with an associated notification. In a behavioural
> sense, the future mechanism wouldnt be appropriate for this.

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...

> If the code is in the servant, what do 1 and 2 mean? My best matching
> of your thinking with the servant-based thinking would be that somehow
> the "client" can submit something into the "worker pool" that
> _identifies_ a function that is in the servant. It would be nice if
> this "work submission" could carry some arguments for presentation to
> the servant.

Right.  Typically, the message in the queue contains all information
necessary, and the AO simply calls a method, passing the message, and it
is the implementation of that method which determines the functionality
of the AO.

 
> A detail that I am labouring is the separation of "calling" (would
> much rather that this was "sending") and execution. Our active object
> has no synchronous i/f with methods for us to call; it is simply a
> "work pool" that we add to. As soon as we make a sync i/f available
> then we go down that road that leads to servant code in the client.

Ahhh.  This fits with the message queue protocol exactly.

> 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.

-- 
Jody Hagins
Drinking is not a spectator sport.
		-- Jim Brosnan