in reply to timeout problem with alarm

Anonymous Monk,
Your problem isn't likely what you think it is. In version 5.8.0, Perl added "safe signals". Even though the signal is getting delivered, it is not acting on it immediately. In even more recent versions of Perl (>= 5.8.1), you can return to the old behavior by modifying a environment variable (PERL_SIGNALS=unsafe). See perlipc and perlrun for more information.

Cheers - L~R

Replies are listed 'Best First'.
Re^2: timeout problem with alarm
by Anonymous Monk on Jul 13, 2005 at 09:46 UTC
    Hi L~R,
    thank's for the very quick and helpful response. According to perlipc I shall (probably) use: 
    Instead of setting $SIG{ALRM} :
    local $SIG{ALRM} = sub { die "alarm" };

try something like the following:
    use POSIX qw(SIGALRM);
    POSIX::sigaction(SIGALRM,
        POSIX::SigAction->new(sub { die "alarm" }))
          or die "Error setting SIGALRM handler: $!\n";

    [download]
[reply]
[d/l]
      Hi,
      this solution works only partly. It produces the expected alarm but the child process is still running 'til the network timeouts.
      So I will probably try 'fork/kill -9' to get rid of the child process...
      Is this a good idea?

      BTW (example; 1 of approx. 40 hosts): 

      > uname -a
SunOS db02 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-Enterprise
> perl -v
This is perl, v5.8.0 built for sun4-solaris

      [download]
[reply]
[d/l]
        Anonymous Monk,
        I am a bit confused. Since kill -9 is "untrappable", it will surely get results though there may be undesireable side effects. I do not know what, if any, cleanup your process would need to do to cleanly exit but kill -9 is friendly. Did you attempt restoring the old signal behavior by setting the environment variable and it didn't work? Perhaps it is something that is beyond your control - more information about your specific situation would help us help you.

        Cheers - L~R

[reply]

In Section Seekers of Perl Wisdom