On Mon, Mar 18, 2002 at 03:57:55AM -0500, Mark-Jason Dominus wrote:
>
> Michael The Schwern <[EMAIL PROTECTED]> says:
> > Use alarm and skip the test if $Config{d_alarm} is false (see
> > t/op/alarm.t for an example). If you think the infinite loop is due
> > to a programming glitch, as opposed to a cross-platform issue, this
> > will be enough.
>
> Thanks very much!
>
> > The only other thing I can think of is to set up a parent process
> > which forks off a child
>
> ARRRGH. NO FORK.
On Mon, Mar 18, 2002 at 04:33:48PM +0000, Nick Ing-Simmons wrote:
> FWIW system() does create a new process on Win32, but fork() does not
> (in only creates a new thread). I have no idea if flock-faking stuff
> on Win32 allows recursive locks by different threads of the same process ...
One of my TODOs (preferably sooner rather than later) was to see if this
bit of ext/Socket/socketpair.t could be generalised enough to end up in
test.pl and provide a portable self-destruct timer
(for infinite loops and other infinite hangs):
BEGIN {
chdir 't' if -d 't';
@INC = '../lib';
require Config; import Config;
$can_fork = $Config{'d_fork'}
|| ($^O eq 'MSWin32' && $Config{useithreads}
&& $Config{ccflags} =~ /-DPERL_IMPLICIT_SYS\b/);
if ($^O eq "hpux" or $Config{'extensions'} !~ /\bSocket\b/ &&
!(($^O eq 'VMS') && $Config{d_socket})) {
print "1..0\n";
exit 0;
}
# Too many things in this test will hang forever if something is wrong,
# so we need a self destruct timer. And IO can hang despite an alarm.
# This is convoluted, but we must fork before Test::More, else child's
# Test::More thinks that it ran no tests, and prints a message to that
# effect
if( $can_fork) {
my $parent = $$;
$child = fork;
die "Fork failed" unless defined $child;
if (!$child) {
$SIG{INT} = sub {exit 0}; # You have 60 seconds. Your time starts now.
my $must_finish_by = time + 60;
my $remaining;
while ($remaining = time - $must_finish_by) {
sleep $remaining;
}
warn "Something unexpectedly hung during testing";
kill "INT", $parent or die "Kill failed: $!";
exit 1;
}
}
}
The idea being that a test killing itself after elapsed time (and failing
to return some results from that test) is better than a test hanging forever
and causing a whole automatic test run to fail.
[and in the case of a busy hang, rather than an idle hang, munching shared
CPU]
Also, did the Windows Gurus work out why the above didn't like Win95?
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
