Boost logo

Boost :

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-03-01 21:35:14

scott <scottw <at>> writes:

> Hi Matthew,
> Hopefully my recent message (new subject "Reactive Objects") clears
> the air.

Yup. I'll reply to that when I've read a couple more times... :)

> > 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( 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 ""? 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".

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 );
    ... // do something

db_client::on_next( ... )
  return_to( process_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...

> 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"?

Not sure what you mean by '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 don't think I mean what I think you think I mean. Taking away the proxies,
the above pseudo-code would become:

db_client::on_next( ... )
  //return_to( process_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);


and the underlying message_handler code (from which both the db_client and
db_server_class classes derive) looks like:

  message& m = dequeue_message(); // client request

  if ( m.return_address )
    message result;

    result.sender = this;
    result.address = m.return_address;
    result.arg1 = m.invoke();


In both cases, the objects are merely dequeueing messages and doing whatever
processing the message requires, possibly generating other messages as a result
(directly, as a return message, or indirectly as a side effect).

Therefore, it is fully asynch. The 'method request' interface is only being
used in the creation and binding of messages.

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at