Re^2: Question On signals in perl

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

Comment on Re^2: Question On signals in perl

Replies are listed 'Best First'.
Re^3: Question On signals in perl by Limbic~Region (Chancellor) on Aug 01, 2005 at 14:59 UTC
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	[reply]
Re^4: Question On signals in perl by anonymized user 468275 (Curate) on Aug 01, 2005 at 15:35 UTC
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	[reply]


Perl-Sensitive Sunglasses
	PerlMonks