Re: [boost] a new release of Join library. Could a review bearranged?

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 
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