"William E. Kempf" <[EMAIL PROTECTED]> writes: > Gennadiy Rozental said: >>> > 1. Boost.Thread with depend on multithreaded version of Boost.Test. >>> 2. Boost.Test will try to use minimal/basic part of Boost.Thread >>> > functionality >>> >>> There's no "minimal/basic part" of Boost.Thread that doesn't need >>> testing. >> >> I did not mean that it does not need testing. What I meant is that I >> will try to use only small part of Boost.Thread functionality. >> What I propose is that we first check that namely this part is working >> (It could be part of Boost.Tet or BoostThread unit test) >> And then move on with rest of your testing. > > Again, how do you "test it is working" if we can't use the Boost.Test > framework! We're in a catch-22 situation so long as you use Boost.Thread > in Boost.Test.
You can do it the way programmers have always done it: simple assert. >>> If I can't rely on it working in my own regression testing, I >>> ceratainly >>> can't rely on it being a part of the underlying test framework. I >>> know this means more work for you, but there's not much to be done >>> about it. You can sacrifice performance, however, in a testing >>> framework. So you can probably get by with nothing more than a simple >>> mutex and a TSS concept with out implicit cleanup, which should be >>> fairly trivial for you to implement. >> >> I would really prefer not to reinvent the wheel with portable >> implementation of Mutex and TSS. > > I understand you not wanting to do so, but I see no alternative. I tend to sympathize with Gennadiy's POV here. Writing minimal portable testing code from scratch is a LOT simpler than trying to do the same in the domain of threading. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost