----- Original Message ----- From: "Yigong Liu" <yigongliu@gmail.com> To: <boost@lists.boost.org>
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.
Pointers to async/synch-derived types, where async/synch are boost::noncopyable starts to look pretty sane.
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.
Yes. I have this lingering feeling that it is a cute abstraction at language level that relieves the developer from the headache of concurrency. Just right at this moment I think I have a chord-ache.
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
While SDL was intended for broad use (system modelling) there has been significant uptake with those people writing state machine specifications. Some of the ITU-T telephony protocols are documented in SDL. SDL is a good tool for that domain. My interest in Join arises from a perceived overlap of concurrency and FSMs.
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.
OK ;-)