Sys::Signal Weirdness

2000-12-08 Thread Bill Moseley

This is slightly off topic, but my guess is Sys::Signal is mostly used by
mod_perl people.  Can someone else test this on their machine?

I have this weird problem where I'm not catching $SIG{ALRM}.  The test code
below is a simple alarm handler that looks like this:

eval {
local $SIG{__DIE__};
if ( $timeout  ) {
my $h = Sys::Signal-set(
ALRM = sub { die "Timeout after $timeout seconds\n" }
);
warn "Set Signal $h\n";
alarm $timeout;
}
print "Test 1 Parent reading: $_" while FH;

alarm 0 if $timeout;
};

This isn't working -- but if I simply comment out the if ( $timeout ) block
it works. 

Here's the output on my machine.

perl test.pl

Starting test2 - WITHOUT 'if ( $timeout )'
Set Signal Sys::Signal=SCALAR(0x810d120)
in child loop 12423
Test 2 Parent reading: 1
Test 2 Parent reading: 2
Test 2 Parent reading: 3
Timeout after 4 seconds  --- good!

Starting test1 - with 'if ( $timeout )'
Set Signal Sys::Signal=SCALAR(0x810d12c)
in child loop 12424
Test 1 Parent reading: 1
Test 1 Parent reading: 2
Test 1 Parent reading: 3
Alarm clock --- huh?

Here's some cut-n-paste test code.  This is what I get on Linux under 5.6.

#!/usr/local/bin/perl -w
use strict;

test2();
test1();

$|= 1;

use Sys::Signal;

sub test1 {
warn "\nStarting test1 - with 'if ( \$timeout )'\n";


   my $child = open( FH, '-|' );
   die unless defined $child;

   loop() unless $child;  # not that this works

my $timeout = 4;

eval {
local $SIG{__DIE__};
if ( $timeout  ) {
my $h = Sys::Signal-set(
ALRM = sub { die "Timeout after $timeout seconds\n" }
);
warn "Set Signal $h\n";
alarm $timeout;
}
print "Test 1 Parent reading: $_" while FH;

alarm 0 if $timeout;
};


if ( $@ ) {
   warn $@;
   kill( 'HUP', $child );
}
}

sub test2 {
warn "\nStarting test2 - WITHOUT 'if ( \$timeout )'\n";


   my $child = open( FH, '-|' );
   die unless defined $child;

   loop() unless $child;

my $timeout = 4;

eval {
local $SIG{__DIE__};
   ### if ( $timeout  ) {
my $h = Sys::Signal-set(
ALRM = sub { die "Timeout after $timeout seconds\n" }
);
warn "Set Signal $h\n";
alarm $timeout;
   ### }
print "Test 2 Parent reading: $_" while FH;

alarm 0 if $timeout;
};


if ( $@ ) {
   warn $@;
   kill( 'HUP', $child );
}
}


sub loop {
$|=1;
my $x;
warn "in child loop $$\n";
sleep 1, ++$x, print "$x\n"  while 1;
}


Bill Moseley
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Sys::Signal Weirdness

2000-12-08 Thread Stas Bekman

On Fri, 8 Dec 2000, Bill Moseley wrote:

 This is slightly off topic, but my guess is Sys::Signal is mostly used by
 mod_perl people.  Can someone else test this on their machine?

That's on-topic, Sys::Signal was written by Doug especially for mod_perl
:) Its use should go away when 5.6.1 will be released.

 I have this weird problem where I'm not catching $SIG{ALRM}.  The test code
 below is a simple alarm handler that looks like this:
 
 eval {
 local $SIG{__DIE__};
 if ( $timeout  ) {
 my $h = Sys::Signal-set(
 ALRM = sub { die "Timeout after $timeout seconds\n" }
 );
 warn "Set Signal $h\n";
 alarm $timeout;
 }
 print "Test 1 Parent reading: $_" while FH;
 
 alarm 0 if $timeout;
 };
 
 This isn't working -- but if I simply comment out the if ( $timeout ) block
 it works. 

Easy. Look at $h -- it's a lexically scoped variable, inside the block 
if($timeout){}. Of course when the block is over the setting disappears,
when $h gets DESTROYed.


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: Sys::Signal Weirdness

2000-12-08 Thread Bill Moseley

At 04:42 PM 12/08/00 +0100, Stas Bekman wrote:
Easy. Look at $h -- it's a lexically scoped variable, inside the block 
if($timeout){}. Of course when the block is over the setting disappears,
when $h gets DESTROYed.

Doh!  I thought about that (which is why I was printing $h).  I shouldn't
debug before sunrise.

Sure is nice to have you back, Stas! ;)



Bill Moseley
mailto:[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]