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