Hello, On 6/12/07, Scott Woods <scottw@qbik.com> wrote:
The oldest solution in C/C++; pointers to?
eg; vector<async<...> *>
smart_ptrs?
I can also vaguely guess why you would want vectors of async/synch but vectors of actor? Isnt it a base and therefore vectors of base would involve slicing?
Don't fully understand the problem space so I wont be embarrassed if these are ignored.
Thanks for the suggestions. Indeed i am thinking that maybe i should use vector<async<void(data)> &(*)> in the first place. The specific application case for this is when we apply Join to some applications of orchestration of data flows. Suppose we are writing code to collect data from 16 external data channels, we can define useful orchestration/synchronization patterns over these channels, e.g. when channel 4,5,6,7 all have data arrived, we call handler method1, when channel 6,7,8,9 have data available, we call handler 2. So users don't want to define/handle each specific channel. By using vector<async<> > (without &/*) i can create a bunch of channels in one shot, which is quite useful. Maybe i should look into some kind of var-array for this purpose. Allowing copying of actor/async/synch objects are dangerous and could mess up how Join works. Each of them maintains status info about on-going messaging. Cw discourage the copying by only allowing defining async/chords in "class" objects which are instantiated from heap and disallowing their use in "struct". I am trying to boost::noncopyable for this. Still learning Join. Its going to take a while. At language level it's quite
simple but the underlying model is less so and is "outside the box". The best I can do at the moment is try to translate the examples into SDL. For reasons I have not truly clarified this translation is only successful in one direction, i.e. Join -> SDL. I suspect that the systems expressible in SDL may be a superset of those expressable in Join. Or more Join-based code is required to support the more complex SDL systems.
Its a bit of a struggle and I dont know that the comparison is even valid.
You are not alone. Generally I found Join does require a bit of mindset change. When i develop the samples, often i found i am back to mindset of shared-memory/locks state, need a bit of effort to adjust it. There are some design "idioms" related to Join, which i collected from the join/Cw papers i have read, i put it in the section of document "OO concurrency design based on Join". Chord is the core of design which defines asynchrony, synchronization and concurrency at the same time. Regarding to the translation between SDL and the Join library, first they are tools for different purposes. The Join library is to provide a minimum set of primitives to build asynchronous concurrent applications, its focus is good integration with C++ language and library features (inheritance, copying...); while SDL is more system modelling and analysis (i dont know SDL, please correct me if i am wrong). Definitely SDL will have more facilities for modeling purpose; If you can find some modeling tools based on Join calculus, that may be more comparable. Also Join's core is asynchronous. I dont know much about SDL and modeling, so please dont take my words too seriously. Thanks Yigong