Hello, On 6/13/07, Mathias Gaunard <mathias.gaunard@etu.u-bordeaux1.fr> 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.
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?
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, 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