Hi Matthew, Hopefully my recent message (new subject "Reactive Objects") clears the air. Some specific responses;
[mailto:boost-bounces@lists.boost.org]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