Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Question On signals in perl

by kprasanna_79 (Hermit)
on Aug 01, 2005 at 13:06 UTC ( #479881=perlquestion: print w/ replies, xml ) Need Help??
kprasanna_79 has asked for the wisdom of the Perl Monks concerning the following question:

Greeting Monk,

When i am going through some code in my project, i found something term called $SIG{HUP},$SIG{TERM}. Can anybody give me some idea about these signals..and also what are the various signals that are present in perl. I am using perl version 5.00_03.

--Prasanna.K

Comment on Question On signals in perl
Re: Question On signals in perl
by Limbic~Region (Chancellor) on Aug 01, 2005 at 13:11 UTC
    kprasanna_79,
    This is one of those questions where it really would take far too long to explain not knowing how much background you already have. In a nutshell, a signal is a way to communicate with a running process. You can tell it to terminate for instance. In most cases, the process can "catch" the signal and handle it appropriately. That's what the code you have found is doing. Read perlipc and then come back with more specific questions if that doesn't answer them.

    Cheers - L~R

      a signal is a way to communicate with a running process

      Sort of, but it is the system, not the programmer that does the communicating and it's restricted to notification by a precise method and of a particular set of possible events.

      One world, one people

        SimonClinch,
        I tend to disagree that it is the system, not the programmer that does the communicating. I don't disagree that the system can initiate and deliver a signal without a user, but that certainly isn't the only way. While it is ultimately the system that delivers the signal, a user can most certainly invoke the signal. If I hit ctrl-C while running a program, I am intentionally sending it a signal. If I type kill -9 <pid> from the command line, I am sending it a signal. Perl even has kill which can deliver a signal at the programmer's whim (with all the caveats outlined in perlport).

        I don't disagree that it is a very limited form of communication, but I prefaced my comment with how hard it was to give a concise answer without knowing the background of the person asking the question. I went on to give a reference where more could be asked.

        I appreciate the comment but I don't believe it does any more to help someone understand signals without knowing how much they already know.

        Cheers - L~R

Re: Question On signals in perl
by blazar (Canon) on Aug 01, 2005 at 13:18 UTC
    When i am going through some code in my project, i found something term called $SIG{HUP},$SIG{TERM}. Can anybody give me some idea about these signals..
    Well, here it's clear you have to do with a hash called %SIG. Check perldoc perlvar:
    %SIG $SIG{expr} The hash %SIG contains signal handlers for signals. For exam- ple:
    and read the docs referenced therein, e.g. perldoc perlipc.
    and also what are the various signals that are present in perl. I am using perl version 5.00_03.
    Signals are not stuff "present in perl". They rather have to do with the OS, although (from the same source as above):
    Certain internal hooks can be also set using the %SIG hash.
    In any case if you're really interested, you may benefit from reading a UNIX programming book, even if not a Perl one.
Re: Question On signals in perl
by Zaxo (Archbishop) on Aug 01, 2005 at 13:31 UTC

    $SIG{HUP} is the handler for the hangup signal which is sent to a process when it loses its controlling terminal. That happens, for instance, when a user logs out with a process running in background. A daemon process has no controlling terminal, so SIGHUP is available and is by custom used to tell the daemon to re-read its configuration files and re-initialize.

    $SIG{TERM} is the handler for the process termination signal.

    See man 7 signal for a list of signals and their default handlers. In most cases the system's default handler is sufficient and you don't need to write one of your own. It's best to not introduce unusual signal handling.

    After Compline,
    Zaxo

Re: Question On signals in perl
by SimonClinch (Chaplain) on Aug 01, 2005 at 13:37 UTC
    A signal is notification to the process of a (nominally) asynchronous event. Examples are:

    INT - the process has been interrupted e.g. by ctrl/c

    HUP - the attached terminal session has disconnected ("been hanged up")

    PIPE - a broken pipe has been detected

    TERM - synchronous termination has been requested

    and so on.

    A simple listing of all signal names can be found by:

    perl -e 'use Data::Dumper; print Dumper( \%SIG );'
    The default signal handler (which generally just terminates the process as soon as it is invoked) can instead be trapped to your own code (sometimes called an AST or asynchronous system trap) by defining a routine reference as the relevant value in the %SIG hash, e.g.
    $SIG{ HUP } = \&MyNoHup;
    or
    $SIG{ PIPE } = sub { warn ( "Broken pipe ignored; traceback follows:\n +" . Devel::trace() ); }
    There are some modules which also assist signal handling, including POSIX

    One world, one people

Re: Question On signals in perl
by samizdat (Vicar) on Aug 01, 2005 at 14:21 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://479881]
Approved by Limbic~Region
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (13)
As of 2014-07-30 14:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (234 votes), past polls