-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]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