Boost Users :
Subject: [Boost-users] Fwd: [signals2][review] little REVIEW
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-11-11 11:23:23
I am forwarding the review below:
---------- Forwarded message ----------
Date: Tue, Nov 4, 2008 at 8:43 AM
Subject: [signals2][review] The review of the signals2 library
(formerly t hread_safe_signals) begins today, Nov 1st : little REVIEW
(first of all please excuse my weak english, I am not a native english speaker)
I am a regular user of boost::signals, so I am very interested by
signals2. I'll review from a user standpoint.
* On the documentation :
- I am surprised to find very little information or rationale about
multi-threading in documentation. We know the library is now "thread
safe" but we don't know exactly what it means. There is only one MT
use case (just) detailed in "tutorial" : what happens when a thread
disconnect a slot from a signal, while another thread calls it. But
there are another interesting MT use cases :
- what if 2 threads simultaneously calls the same signal ? How to
mutex slots in this case ? Are slots automatically excluded by an
hidden mutex ?
- What if a thread adds a slot to a signal while another calls it ?
Is the slot added after signal call ?
There should be tutorials and explanations for these cases, IMO.
- About rationale : why is there special signals2::mutex ? May we use
boost::thread::mutex for mutex template ? What are
advantages/drawbacks of choosing signals2::mutex or
- Use of "postconstructible" or "predestructible" classes is rather
obscure, and should be tutorialized / better documented.
* On interface :
- Very close from original signals interface : no particular comment.
* On test suite / test cases :
- I cannot see any MT test case (from the documentation, in
"acceptance tests" section at least). It's rather surprising. I cannot
imagine there is no test case for MT (calling a signal while
disconnecting slot etc..). In particular, I'd whish to see if this
library is robust in a multi-core environment and run test cases in
this environment (I know cases where a library is perfectly thread
safe on mono-core, even hyperthreading, but fails on multi-core). At
least, there should be a rationale explaining why this library should
be robust in a multi-core environment (especially with a proprietary
* Final statement :
All in all, I think this library is very close to be accepted as a
Boost library, but without MT test cases and MT documentation, I can't
give a total agreement for now. I have little doubt this library is MT
tested and robust, even in a multi-core environment, but I have no
real clue to assert it.
Feel free to ask me further details.
THALES Communications France
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net