On Tue, 17 Feb 2004 15:27:21 +1300 "scott" <scottw@qbik.com> 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