----- Original Message ----- From: "Frank Mori Hess" <fmhess@speakeasy.net> To: <boost@lists.boost.org> Sent: Wednesday, November 12, 2008 4:01 AM Subject: Re: [boost] Fwd: [signals2][review] little REVIEW

On Tuesday 11 November 2008 11:23, Stjepan Rajko wrote:

...

---------- Forwarded message ---------- From: <Jean-Christophe.BENOIST@fr.thalesgroup.com>

...

* 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 signals2::mutex).

It's not obvious to me how to write a test for the library's thread-safeness that is any more focused than "we did some signals stuff in multiple threads and the program didn't crash". It's sort of like writing a test for memory leaks. What you need is a debugging tool, like what valgrind's helgrind tries to be. Then you can have your multi-threaded test program, and the test is whether or not the debugging tool detected any funny business (like multiple threads messing with the same variable without locking).

Yes I know that doing test on a multi-threading environement is not eassy, but we can not deliver a thread safe library without the minimal unit testing coverage on all the functionalities concerned by the multi-threading. Please could you take a look on hwo the tests of the Boost.Thread library are done. Regards, Vicente