RE: [boost] Re: [Threads] Reactive Objects

From: scott (scottw_at_[hidden])
Date: 2004-03-04 19:05:45

> [mailto:boost-bounces_at_[hidden]]On Behalf Of scott
> Sent: Thursday, March 04, 2004 1:04 PM
> To: boost_at_[hidden]
> Subject: RE: [boost] Re: [Threads] Reactive Objects

Responding to myself and

> > [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt
>

Matthew.

> > Then all the proxies need to do to yield a method-based
> > interface is bind
> > the address into the message before queueing.
>
> Read and re-read this cos I was determined to not be
> suggesting something that you already had :-) My best
> guess is that I have introduced a third form of
> dispatch, where m.dispatch_bound() would evaluate true?
>
> >
> > > If we can agree on something here then we would have a
> > complete target for
> > > something built on boost.thread, i.e. there are no other "areas"?
> >
> > I think messaging between thread contexts is a useful target.
>

Hmmmm. Unfortunately I have run headlong into a nice, gnarly area. Thought
I should visit this with you before going to the next step.

If reactive objects are intended as a technique for management of
threads then syntax, conventions and idioms of usage are going to be
important (of course). We hadn't tackled this to any great extent, for
the reactive object library. I am specifically referring to how reactive
objects are to be "addressed".

On first consideration it can seem to be a non-issue; the address of
the recepient is the address that I am holding in this variable "db_server".
The
picture I have is complicated by the nature of the beast we are trying
to tame; i.e. threads.

I believe we have the goal of instantiating objects that are C++
representations of threads. This is not new. What _is_ possibly new
(and different to the current boost::threads) is that there is an
equivalence between the life of the C++ object and its thread. If
the thread terminates then naturally the associated C++ object should
no longer be "of the ActiveWorld".

void
getting_started()
{
        my_db_server server;
        db_open open;

        server.send( open );	// <--- !!!
}

At the point of initiating the transmission of "open" to "server" there
is no guarantee that the object still exists. At least I/we have suggested
such things in recent discussions. The example code is a bad example with
the automatic scope of "server" to further highlight the slight tangle that
this issue creates.

There is a lot of background behind the following, but rather than taking
anyone on a confusing stroll through the possibillities, here is what I
would propose;

// Example intended to show technique rather than
// final packaging.

typedef unsigned long	reactive_address;

reactive_address server = reactive_create<db_server>();

void
window::on_create()
{
        send( db_open(), server );
}

Essentially, machine addresses are verboten. They cannot be trusted. So
instead there is some kind of "id", or "handle" that is the only mechanism
by which a reactive object may be referred to.

Code behind "reactive_create" would need to maintain a map of the pointers
that we would otherwise have used. This map would be maintained in a
thread-safe manner and on dtor of an object the associated map entry
should be removed.

The send primitive needs to perform (thread-safe) lookups.

Where a message is sent to an object no longer in the map, the message
falls on the floor.

Ta,
Scott

ps:
matt - you may notice that this implies type info of recipient is gone :-(