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

From: scott (scottw_at_[hidden])
Date: 2004-03-01 19:35:28

Hi Matthew,

Hopefully my recent message (new subject "Reactive Objects") clears
the air. Some specific responses;

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt
> Sent: Tuesday, March 02, 2004 12:01 PM

> Yes, I envisage things in the same way.  Although with the 
> exception that
> I want the messages to be automatically routed to a function 
> that can deal 
> with them, rather than having to go through a message 
> inspection switch.
> In this way, there is no 'next message' in a sequential sense 
> - the next
> message that arrives in the object's queue will go to its pre-defined
> destination, and when the response you're referring to 
> arrives, it too will 
> go its own destination.
> 
> > The closest thing to a "return address" in this model is the active
> > object that sends a message, i.e. every message sent is 
> augmented with
> > who the sender was. In the ActiveObject (pattern) model the return
> > address is the address of the next machine instruction after the
> > Method Request.
> > 
> 
> Yes.  Although, the sender could bind a return address into 
> the call in this
> model also - it would have to be the address of a method in 
> the sender.  This
> would allow the automatic routing that I think is preferable 
> to messages.
> This model is still working by passing messages, mind, but 
> the messages have
> extra data with them to skip the dispatch processing.

Hmmmmm. We are either still confused or we have different targets.
Since I exist in the former continuum, the following is mostly for me.

If there were a callback (called by thread after de-queueing a
message) that went something like;

db_client::on_next( ... )	// User pressed the "next" button
{
        if(db_server.next( current_record ) == END)
        {
                // Wrap to the beginning
                db_server.first( current_record );
        }
}

How do you "bind a return address" to the point just after the
"call" to "db_server.next"? Even if you do manage this syntactically,
is the call to "on_next" suspended somehow? Obviously the same
"suspension" would have to occur for the call to "db_server.first".

I suspect that you are thinking (and have been doing your best to
tell me) that the "asynchronous calls" will be effected by the
threads in each active object. They will simply "chain"? If that
is the case then I see some difficulties. The least would be the
loss of throughput relative to "true" async calls. More importantly
I think you might be calling back into an object (e.g. the db_server
calling a response method in a client) that otherwise has no
idea that the original request has been completed. As a "model
of operation" this seems at least as foreign as the "fully async"
model that SDL pushes?

> 
> I'm not referring to inherent harmful-ness, just that 
> switching to dispatch
> messages is more cumbersome and error-prone that binding the 
> dispatch address 
> into the message. Provided your syntax makes the binding 
> clean and easy, of
> course.

Understood. Recent message hopefully explains my use of "switch", i.e.
it is always auto-generated code.

> client: send message 5 to server
> server: if (message == 5) perform function
> 
> instead of:
> 
> client: send message 5 to server.handler_for(5)
> server: perform function
> 
> which can be made equivalent to the semantically easier:
> 
> client: invoke "service" on server
> server: perform function
> 
> Obviously this is a trivialisation, but I don't see what I'm missing.

In your version of things the sender is selecting the code to
be executed in the recipient. This is the fundamental difference.
In my version the client cannot assume anything about the receiver.
There are perfectly valid examples of "active objects" in my ActiveWorld
that _must_ be able to receive _anything_. One example is a proxy
object that accepts any message and forwards it across a network
connection to an active object in a remote process.

Also, the active object may (or may not :-) be a state machine.
The sender (i.e. a client) cannot truly know which method to call
as the correct method is state-dependent. The runtime switch issue
that exists for this circumstance is similar to the issue that exists
for selection of method call vs switching on message. One strategy involves
knowledge of the recipient, the other doesnt. Well, other than that
all active objects are capable of receiving messages :-)

> > 
> 
> Yes.  I hope I've cleared up my understanding of the model of 
> execution?

For sure.

Cheers,
Scott