Re^2: System call + signals = bad return code?

So, working on my theory that $? and $! are being trashed because of the call to the signal handler, I localised the variables $? and $! which has made a positive difference. Here is the code.


$SIG{ALRM} = sub {
    local $? = 0;
    local $! = 0;
    print( "Alarm triggered in $$\n" );
    unlink('/doesnt/exist');  # this will definitely fail
};

alarm(2);
my $rt = system("sleep 4");
print "system returned $rt, \$? is $?\n";
[download]

And the output is -

Alarm triggered in 26346
system returned 0, $? is 0
[download]

Give it a try in your code. Let me know how is goes.

Comment on Re^2: System call + signals = bad return code? Select or Download Code

Replies are listed 'Best First'.
Re^3: System call + signals = bad return code? by papidave (Pilgrim) on Oct 01, 2007 at 12:41 UTC
Doing anything complicated in a signal handler is scary dangerous. The most common problem lies in memory management -- if your code attempts to malloc() a buffer when the main code is already in malloc(), your heap can get corrupted. It won't happen all the time, and it may not even happen often, but it can happen and it's very hard to debug. The Signals section in Chapter 16 (IPC) of the Camel explains the rationale for this further -- but the general rule of thumb is that your handler shouldn't do anything more complicated than updating a variable, e.g. `my $interrupted = 0; $SIG{ALRM} = sub { $interrupted = 1; };` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: System call + signals = bad return code?
by papidave (Pilgrim) on Oct 01, 2007 at 12:41 UTC

all

often

The Signals section in Chapter 16 (IPC) of the Camel explains the rationale for this further -- but the general rule of thumb is that your handler shouldn't do anything more complicated than updating a variable, e.g.

   my $interrupted = 0;
   $SIG{ALRM} = sub { $interrupted = 1; };
[download]

[reply]
[d/l]