Re: indefinite hang in ./perl -I. -MTestInit ../ext/IO/t/io_multihomed.t

[email protected] (Abe Timmerman) Tue, 30 Sep 2003 00:29:00 +0200
Newsgroups perl.daily-build
Organization ztreet
Message-ID <[email protected]>
Op een zonnige herfstdag (Monday 29 September 2003 22:00), schreef Rafael 
Garcia-Suarez:

> David Landgren wrote in perl.daily-build :
> > Which leads me to think that possibly some sort of dead man switch is
> > needed: if a test doesn't phone home within a set amount of time it is
> > forcibly evicted. 600 seconds sounds reasonable to me.
> >
> > I'm not sure at what level this should be, though. I'd tend to argue
> > for the test harness program itself.
>
> The problem is that the test harness program should use a minimal set
> of features from perl, because it's used to test perl itself.
>
> So I'd suggest to handle this from the smoke kit : it can be run with
> another perl, known to work with alarms and all this kind of stuff.

If someone could teach me how to do that (in a portable way), I'd be grateful. 
The way I see it is: "the harness (either TEST or harness) should have direct 
access to the 'pid' of a test and is thus capable of handling that process in 
sort of a portable way". From within the Test::Smoke-suite I can't see a way 
of handling individual tests in a portable way. I can catch each test's name 
(from STDOUT) but I know not of a portible way to influence that process.

I agree with you that the harness *should* only use "basic" perl to handle the 
testsuite (as that is what we are testing, up to a certain point), but on the 
other hand, the harness is the only process that has direct access to the 
test-process information to intervene with it.

In short I'd love to handle this from Test::Smoke (as it seems to be the 
"level" at which this should happen), but I can't see a way of solving this 
portable. (Please enlighten me.)
Good luck,

Abe
-- 
(*) Before the testing posse is on my case :-) let me preempt them by
saying that fake networks don't really help here.  You'll be testing
a fake network.  That proves that the module worked on a fake network.
That's great.  Like drinking decaffeinated.
                                   -- Jarkko Hietaniemi on p5p @ 2001-11-22