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/