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?

Reply via email to