Re: [boost] a new release of "Join" asynchronous concurrency library

From: Yigong Liu (yigongliu_at_[hidden])
Date: 2007-06-17 13:43:55

Hello,

On 6/13/07, Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:
>
>
> That would probably impose the use of dynamic allocation of each
> channel, which would require memory management.
> Following RAII, the vector should therefore own the pointees, so
> ptr_vector should be used.

 I have been trying to avoid dynamic memory allocation, since async<> /
synch<> methods are kind of message queues using STL containers and STL is
value-semantics oriented. Inside Join's "base" framework, dynamic memory
allocation is only used for chord creations, which is really dynamic, and
which is owned by the parent actor<> thru a vector of shared_ptr. For
creating a bunch of "anonymous" async<> / synch<> methods or data channels,
i have been using vector<async<>/synch<> >, till we hit the handling of
copying. Thanks for pointing out ptr_vector, i'll look into it.

Copying, or rather moving, is only needed when growing (or shrinking,
> but vector doesn't support that anyway).
> But still, shouldn't channels be movable anyway?
>
> By "movable", are you referring to the semantics similar to std::auto_ptr?
the transfer of ownership? If so, async<> / synch<> methods can not or
difficult to be movable. Since if we "move" a async/synch method from one
actor to another, we need to destroy / cleanup all chords in original actor
which the moved async/synch participate in and which will never become ready
to fire now since the "moved" channel will never send messages again.
Otherwise message leakage will happen.
Also in the original join-calculus, the channels and the reaction rules to
handle messages at these channels are defined in the same place: join
definitions. We are trying to use a class (inheriting actor<>) to simulate
the join definition. It seems to me that active classes (inheriting actor<>)
should be the owner of their async / synch methods and these methods are not
copyable/assignable/ movable.

Thanks
Yigong