Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by papidave (Monk)
on Oct 01, 2007 at 12:41 UTC ( #641869=note: print w/replies, xml ) Need Help??


in reply to Re^2: System call + signals = bad return code?
in thread System call + signals = bad return code?

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; };

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://641869]
help
Chatterbox?
[choroba]: As discussed in Using the DATA file handle for ARGV, I usually start my "fun" scripts with *ARGV = *DATA{IO} unless @ARGV;
[choroba]: this was just a remainder
[Discipulus]: ah thanks i forgot that thread (even if i saved it in my homenode)..
[Discipulus]: the node i discovered yesterday nigth was also interesting

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (6)
As of 2016-12-06 08:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    On a regular basis, I'm most likely to spy upon:













    Results (101 votes). Check out past polls.