forwarding to boost on the assumption that it was your intention. apologies if i got that wrong. -----Original Message----- From: scott [mailto:scottw@qbik.com] 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@atdesk.com]

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