[mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt Sent: Saturday, February 28, 2004 2:03 PM
This method will be another proxy (e.g. non_void_with_param_returned) that in turn, queues the result. This decouples the scheduler from the recipient of the results; eventually the thread working on that task list will reach the "results task" and will run that.
So you have a callback, the invocation of which queues a message?
Sorry - yes. Callback means something specific and different in my world but can see that your use is correct.
The "damn" part of my response stems from the fact that I believe the "Method Request" model is not viable as a model of execution for the thread toolkit. It is simply wrong and bending it to this task is a deadend.
I don't understand why you think this. I think the active object wrapper indicates that you can use the method request model to encapsulate the interactions between the threads. There's no reason why it can't be the interface layer on top of a message passing system, provided that the result does yield simpler interfaces.
I should be careful here that I'm not just adding confusion. In this context "Method Request" and "synchronous method call" are used to refer to the same thing. A model of execution involving (typically) use of a machine stack and pointer to implement auto "jump and return" behaviour. Servant code (i.e. the callbacks :-) is executed in response to the de-queueing of messages. If such a callback was to make a "Method Request" to another active object, how does your model of execution cope with this? In the SDL world the callback typically terminates and you enter a "waiting for the next message" state (just like a GUI message pump). That next message is hopefully the results of your previous request, but could be many things including error messages. 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. What were you going to do with that? Continue execution? But you would be forced to wait for the async return of results. Do you have some way of suspending the current callback and allowing others to run? Then when the current response arrives, resuming execution at that machine code address? Of that particular execution frame (there may be multiple pending instances)? That would be something :-) I do remember some code that used setjmp/longjmp in the old days, to implement LWT'ing. It was actually good and did achieve something like what I describe above. But I mention that as one of those things we used to do when dinosaurs roamed. And we didnt know any better.
What is SDL? I parse it a Simple Directmedia Library...
Yes, this demonstrates what you're doing quite clearly. But, it also demonstrates the weakness that the logic is switch-based, which is kind of what C++ was invented to circumvent...
Erm, yes. Admirable but for some strange reason they havent removed the keyword yet. Until they do I will exploit the efficiencies therein. Have I shown you my collection of "goto"s yet? ;-) In my particular circumstance there is _no way_ to implement this switch as a compile-time activity (even though I so wanted to). The major reason is that I (well actually a scheduler) must dispatch the message to a callback based on a runtime integer. Integer? Small, set of known possible value? Well switch will do for the moment :-)
If you can bind the code-to-be-excuted to the content of the message, then the need to inspect the message and make a decision is removed, and this is an advantage you could derive from a method request model.
Yes see were you are coming from. Suspect that our directions and understandings separate around "model of execution" (machine call vs SDL send) and that this is another symptom. If you can make it work then I think I can see that the result would be "more intuitive".
With a bunch more scaffolding this is what my reactive_object code looks like;
int db_interface::transition( machine_state<READY>, typed_bind<interface_open> & ) { client.insert( sender() );
send( status, sender() );
return READY; }
This seems very nice, although it seems to be more about the state machine code than the communicating objects.
Thank you. That could be the best (unintentional) compliment I could hope for. If you have other code that accepts an inbound object, remembers who sent it and responds with an object containing the lastest status - and all across thread boundaries - and a reviewers response is essentially "where has the comms gone"; then my work here is done :-)
I understnad what you're doing now. What are the drawbacks you want to address in your code?
Thanks for the question. I will roll the response into a new subject. I think.