Hi Yigong, I have just see your two libraries Join and Channel on the vault, excelent work. For the moment some superficial comments and questions? 1. There is a lot of NULL constants in the code that should be replaced by 0 :) 2. In the Erlang example you state "Erlang check messages types during runtime, if Erlang server receives a unexpected message, "Other -> ..." section is invoked. In Join based server, the message types are defined at interface and checked by compiler. Because sending a message to Join based server is to invoke its async methods, so compiler can prevent invoking unsupported methods." Can we emulate the "Other -> ..." semantics with Join? What about AnyMessage and Timeout? 3. FYI, there is another join library for the language Scala (jolib). Scala provides also an actor library based on Erlang, but you know surelly that already. How jolib compares to your library? 4. select template in actor.h could be replaced by mpl::if_c template <bool flag, typename T, typename U> struct select { typedef T result; }; template <typename T, typename U> struct select<false, T, U> { typedef U result; }; 5. bitmap seams a good candidate to boost template <size_t size> struct bitmap 6. In the Comega comparaison you state "chord override Cw and Join have different rules for chord overriding." Which ones and which is the rationalle? 7. In the CCR comparaison you state "In CCR, arbiters roughly correspond to chords in Join. However arbiters take more roles than chords:" Do you mean that chords could be defined in terms of arbiters? is arbiter a lower level concept than chord? and "In CCR, ports (the message channels) are totally independent from join-patterns or arbiters, instead arbiters are attached to ports. Ports can be used independently from arbiters as plain message queues. However in Join, the async<> / synch<> methods or channels must be attached to chords before they can be used (invoked), otherwise exceptions will be thrown. This is more consistent with original join-calculus and Jocaml." Why not defining a independent port, which should be already useful (the CCR port recall me the future_stream), and let async<> / synch<> the actor and chord dependency? 8. Could you provide a more deep comparaison to C#.Joins? 9. "The Join library is implemented as three layers:", Are the interfaces of the base layer port public? They do not appear on the "Synopsis of Join Classes" 10. I would like to cuple asynchronous methods and futurers, giving the to possibility asynchronous methods to returnn some data. Do you think that this is possible? 11. The name of the files and the classes do not match too much. E.g. the port class is found in the file join_base.hpp, and the port.h files contains sync_v/async_v sync_f/async_f. Could you do something? 12. Do you plan to provide variable number of arguments to sync/async methods and to chords using the Boost.preprocesor library, and why not the C++0x varying templates feature? 13. If actor and joint are the same, why not define a typedef? 14. As the goal of such a library is to scale better than mapping concurrent components to threads, a comparaison on performance and number of actors should be included. People need this to adopt the paradigm change. To finish, do you intend to submit your Channel library to boost? Best regards ____________________ Vicente Juan Botet Escriba