Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-12 09:44:54

Hi Yigong,

I have just see your two libraries Join and Channel on the vault, excelent

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?

"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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at