RE: [boost] Re: [Threads] Simple active object wrapper, take 2

From: scott (scottw_at_[hidden])
Date: 2004-02-29 16:32:28

> [mailto:boost-bounces_at_[hidden]]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...
>

http://www.sdl-forum.org/

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