in reply to Question On signals in perl

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

Replies are listed 'Best First'.
Re^2: Question On signals in perl
by anonymized user 468275 (Curate) on Aug 01, 2005 at 14:49 UTC
    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

      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

        Yes, but your use of the expression, "a way to communicate", suggested IMO far more flexibility than actually exists.

        In regard to who delivers the signals, the only option was not to mention this or to mention it correctly. Signal handlers are also known as asynchronous system traps precisely to make this point clear.

        One world, one people