On Fri, 2004-08-27 at 11:03, Andrew Pimlott wrote: > And most tests, even of threaded code, will call T::B from a single thread > anyhow.
How do you know what tests people will write? How do you know where people will run those tests? > There are two ways to do the compromise: > > 1. Go thread safe in T::B if threads has already been used, which just > requires the programmer to use threads (or use a library that uses > threads) before T::B--which he probably would do anyway. use_ok( 'Some::Module::Requiring::Threads' ); > 2. Go thread safe in T::B only if the programmer requests it > explicitly. I would favor this, because I still see perl threads as > experimental. It doesn't matter how *you* see Perl threads if users who may run your tests see them as worth using -- everyone using ActiveState's Perl for example, or all of Red Hat's users (I believe), use threaded Perls. How does the programmer know the characteristics of all of the Perl installations on which the test will run? How does he know the current and future internals of all supporting modules and whether they use threads or not? If you can't know all of this, then you have two options: 1) Ignore thread-safety altogether always. 2) Try to be thread-safe always. Test::Builder takes the second approach. -- c