I was wondering if someone could explain well what good signals are for (particularly what they can do other things can't) and give a full, straight forward, example. I don't mind someone just redirecting me somewhere else that they know there's a good explanation or example. Thanks!

Signals are a great way for one process to, well, "signal" another process.

Signals are also how you can "notify" a running program that something "interesting" has occurred: you can signal a "Ctl-C event" (SIGINT), a memory access error (SIGSEGV), floating point error, or some other "condition" that occurs "asynchronously" to the program. Some condition where the program might need to take some *immediate* action as a result.

'Hope that helps .. PSM

Well, under Linux you can use the SIGSTOP signal to "pause" a process. That's what happens when you press CTRL-z. Or you can do it manually:

and then to resume

If you're really concerned about your clock cycles, I guess it could be used to put busy processes to bed during the off hours.

Signals are a way for one process to tell another, "Something has happened. Drop what you're doing and take care of it, and then go back to what you were doing." A person writing code in, say, C, will write a signal handling function that causes the program to take care of the situation. The programmer will set up his program to ask the operating system (in your situation, probably Linux) to transfer control to this signal handling function upon receiving a particular kind of signal. After the signal handling function returns control, ordinarily the program will resume where it left off.

In addition to some of the examples mentioned in previous posts in this thread, when you run a text editor in an xterm window and then you resize that window, a signal gets sent to the text editing process which notifies it that the window size has changed. The text editor then finds out what the new window size is and rearranges the text in the window.

One of the examples mentioned above is rarely handled by the program itself: SIGSEGV. This is because SIGSEGV is usually generated by a bug in the program, and if there's a bug in the program, the signal handling function ordinarily should not rely on any data at all being usable. The signal is still valuable, however. You can make use of it not by writing a signal handling function for that signal, but by running your program under a debugger such as gdb. If SIGSEGV happens to your program under that case, gdb will notice it and allow you to see which functions were active at the time your program blew up, and what values were currently stored in variables.

A brief introduction to signals may be found here.

Hope this helps.

1 members found this post helpful.

Signals solve the problem of responding to events that happen asynchronously. Instead of periodically testing whether a specific event has occurred (such as data arriving from some source like a serial interface), a program can trap the event, and only respond to it when it actually occurs.
--- rod.

So golmschenk - question answered?

"Signals", just FYI, are one example of "Interprocess Communications" (IPC). A subject brilliantly discussed in the most excellent Beej's Guide to IPC

http://docs.hfbk.net/beej.us/bgipc/

Enjoy .. PSM

Yes! Thank you much all!