On Mon, Mar 07, 2005 at 11:45:52AM +0100, S?bastien Aperghis-Tramoni wrote: > > * As mentioned, Devel::Cover is not perfect and often screws up test > > results, threading particularly is a problem, so that it will give > > false negatives. This is a common problem, one example is Test::More. > > An interesting question would be: from all the CPAN Testers reports, > how many perl are built with thread support enabled?
Well, for one, anyone using OS X or ActiveState. Those are the ones I know for sure. Probably Fedora. I'd hazard to guess that many pre-built Perls these days have ithreads enabled. > The next interesting question is: how many modules use/need threads? > If I believe CPANTS, not much. > > sqlite> SELECT dist.id, dist.dist, dist.author, prereq.requires > FROM dist, prereq WHERE prereq.requires like '%hread%' > AND prereq.requires not like '%ail%' AND dist.id=prereq.distid; > > returns 17 results, 16 of which are in the Thread::* namespace (and > are released by Elizabeth Mattijsen). The only one left is SNMP::Server. Test::More does not declare its optional dependency on threads. It will simply use them if available. I can't speak for anyone else but I wouldn't be surprised if other modules did what Test::More does: not use threads itself but test to make sure it works with threads on. > I never dealed with thread problems, but from reading the Perl > documentation, I always had the feeling that Perl thread support > has never been considered very stable. Yes, but its at least usable now. > This is to say: ok, maybe Devel::Cover don't deal very well with > threads, but if there's so few modules on the CPAN that use threads, > maybe it can be considered as a low priority issue. Devel::Cover still has problems with other constructs, though its gotten better as of late. Perhaps a compromise is for the coverage runs to only be reported back as coverage and not test results?