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

From: scott (scottw_at_[hidden])
Date: 2004-03-02 16:49:56

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt

<snip>

> > How do you "bind a return address" to the point just after the
> > "call" to "db_server.next"? Even if you do manage this 

<snip>

> 
> You can't (as far as I know, anyway).  So the return address 
> has to be a
> method in the object that invoked the call.  The client has 
> to be refactored
> to (pseudo-code): 
> 
> db_client::process_next( ... next_record )
> {
>   if ( next_record == END )
>   {
>     // Wrap to the beginning
>     return_to( process_next ) = db_server.first( current_record );  
>   }
>   else
>   {
>     ...  // do something
>   }
> }
> 
> db_client::on_next( ... )
> {
>   return_to( process_next ) = db_server.next( current_record );
> }
> 
> This assumes that the return_to<> proxy can be created to 
> update the other
> proxy (the method request emulator) to bind the return address...
> 
<snip>

Yep. All straight now. I know understand your breakdown of calls
to callbacks is very similar to that inherent in SDL. And yes, you/we/it
are fully asynchronous.

> the above pseudo-code would become:
> 
> db_client::on_next( ... )
> {
>   //return_to( process_next ) = db_server.next( current_record );
>   message m;
>   m.sender = this;
>   m.address = bind(&db_server_class::get_next_record, db_server);
>   m.arg1 = current_record;
>   m.return_address = bind(&db_client::process_next, this);
> 
>   db_server.enqueue_message(m);
> }

I'm assuming you prefer this to the reactive object version? Which
does a pretty good job of hiding the comms :-) Oh yeah, and doesnt
require selection of the method to call in either the receipient
or the client (on response), i.e. at the point of making a method
call.

Maybe we're down to a matter of taste?

<snip> 

> > 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.
> > 
> 
> Yes - I was assuming a published interface from the 
> (re)active objects, although
> you do present a good example of somewhere this can't be done.  For
> this individual case, you can ditch the method-emulating 
> proxies and deal
> with the underlying message queues directly.
> 
> > 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 
> 
> I hadn't realised how integral the state machine was to your 
> design until I 
> read your other post.  Still, if you are doing dispatch on 
> both message code 
> and object state, it can be simplified to bind the message to 
> a per-message
> code dispatch function which then dispatches on object state.

Characterizing of reactive objects as a framework for state machines
would be a little bit sad. I'm not sure it was your intention to say
that so just in case others are listening, I will elaborate from
my POV.

The messaging facillity that I believe is a fundamental requirement
of the alternate threading model (i.e. Reactive Objects?),
has no understanding of state machines. It was a requirement of the
design that it did not. Proof of success has been the subsequent
ability to implement a wide variety of active objects, e.g.;

* windows, dialogs and controls,
* worker threads on a server
* TCP connections (connected and accepted)
* proxy objects
* database server state machines
* virtual machine threads

The messaging facillity has _no understanding_ of what the recipient does
with a message. Proxies and state machines were intended to highlight
the benefits of that design.

To summarize; the Reactive Objects that I currently consider our target
would communicate via a similar mechansim and there would be no
assumption that a Reactive Object was a state machine, or a proxy, or
anything except an object that accepts messages.

Cheers,
Scott