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