The trouble with signals is that there are so few of them and we can't add more without breaking the ABI.
If you need to send more types of messages, there are other IPC mechanisms.
A guide to Linux signals
11–20 of 37 posts
Re: A guide to Linux signals
#12For a more in-depth look at Signals, there's Michael Kerrisk's Linux Man Pages on Signals [1]. AFAIK, the best reference on Signals is in the book by Stevens and Rago [2].
[1] http://man7.org/linux/man-pages/man7/signal.7.html [2] Advanced Programming in the Unix Environment, Second Edition
Re: A guide to Linux signals
#13Earlier quoted context omitted.
> They are much nicer to use than the Windows equivalent. Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.
Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).
Much of the IPC stuff Linux has to do with signals is done with window messages on Windows, which is usually nicer as you get to handle it in a defined state rather than, say, in the middle of a syscall.
Re: A guide to Linux signals
#14Earlier quoted context omitted.
> They are much nicer to use than the Windows equivalent Seriously? You find a system with global events where you must perform your own resource book-keeping to clean up the correct resources nicer than structured exception handling?
Yes as soon as you have to support both 32 and 64 builds in a multi-threaded program that is using the C run time library. This of course is just my opinion :)
Why is SEH a problem in that case? SEH is occasionally flaky but much nicer than trying to handle SEGV.
Re: A guide to Linux signals
#15Earlier quoted context omitted.
Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).
Much of the IPC stuff Linux has to do with signals is done with window messages on Windows, which is usually nicer as you get to handle it in a defined state rather than, say, in the middle of a syscall.
Signals are not generally used for IPC on Linux. Also you can handle them orderly along with other fd events using the standard & portable self-pipe pattern or Linux-specific signalfd.
Re: A guide to Linux signals
#16Earlier quoted context omitted.
> They are much nicer to use than the Windows equivalent. Strongly disagree. It's hard to make different signals cooperate. Vectored exception handlers in Windows have built-in support for arbitrating between different users.
Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).
> What is hard about making signals cooperate?
Library A wants to handle SIGSEGV for memory mapping X. Library B wants to handle SIGSEGV for memory mapping Y. Which of them calls sigaction? What if both do? What if then unload one of the libraries?
Windows handles this interaction sanely. Sigaction does not.
> raise() is supported on Windows, but kill()
Windows splits the jobs of signals into structured exceptions and APCs. You can definitely send an APC to another thread: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
Re: A guide to Linux signals
#17A note: SIGHUP is far from obsolete in its original purpose. We may have stopped using modems but people still log in to Unix machines in ways that can get disconnected. If you SSH in to a machine and your SSH session is cut off by a network issue, your shell (and any command you have running) will get a SIGHUP.
There's more than that in SIGHUP. It's sent to the process group owning
the terminal[1] (/dev/tty[1-X], /dev/pts/*) when said terminal is closed. Your
shell, Midnight Commander, Vim, Emacs, and what not terminates when you close
your terminal emulator window.
[1] I don't quite remember what happens to other process groups, since you could have some background jobs stopped.
Re: A guide to Linux signals
#18A note: SIGHUP is far from obsolete in its original purpose. We may have stopped using modems but people still log in to Unix machines in ways that can get disconnected. If you SSH in to a machine and your SSH session is cut off by a network issue, your shell (and any command you have running) will get a SIGHUP.
There's more than that in SIGHUP. It's sent to the process group owning the terminal[1] (/dev/tty[1-X], /dev/pts/*) when said terminal is closed. Your shell, Midnight Commander, Vim, Emacs, and what not terminates when you close your terminal emulator window. [1] I don't quite remember what happens to other process groups, since you could have some background jobs stopped.
Yes, and using the 'nohup' utility you can effectively block the delivery of SIGHUP to a particular process, to ensure it does not terminate when you close your SSH connection.
Re: A guide to Linux signals
#19Earlier quoted context omitted.
There's more than that in SIGHUP. It's sent to the process group owning the terminal[1] (/dev/tty[1-X], /dev/pts/*) when said terminal is closed. Your shell, Midnight Commander, Vim, Emacs, and what not terminates when you close your terminal emulator window. [1] I don't quite remember what happens to other process groups, since you could have some background jobs stopped.
Yes, and using the 'nohup' utility you can effectively block the delivery of SIGHUP to a particular process, to ensure it does not terminate when you close your SSH connection.
Awesome, I knew nohup could be used for that, but hadn't worked out why it was called that.
Re: A guide to Linux signals
#20Earlier quoted context omitted.
Linux (Unix) signals are per-process. What is hard about making signals cooperate? Are you referring to a signal generated while in a signal handler? raise() is supported on Windows, but kill() isn't (directly, signals don't seem to be well supported as an IPC mechanism on Windows -- although there appear to be kill() style mechanisms).
> What is hard about making signals cooperate? Library A wants to handle SIGSEGV for memory mapping X. Library B wants to handle SIGSEGV for memory mapping Y. Which of them calls sigaction? What if both do? What if then unload one of the libraries? Windows handles this interaction sanely. Sigaction does not. > raise() is supported on Windows, but kill() Windows splits the jobs of signals into structured exceptions an…
It's actually alarmingly common for Windows C/C++ apps to paper over crashes with SEH try { } catch (segfault) { /* seems to work */ } this way. Even Microsoft's own apps used to do it, maybe they still do. You run into this when running random apps under a debugger.