Timeline for Why does `kill -l` not list signal numbers of 32 and 33?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 29, 2016 at 7:18 | comment | added | SlySven | They are used internally by the RT pthread library - and in the past there would be three not two because a different system used that many for internal purposes. From a coding point of view you are not supposed to use compile-time constants for the signals above SIGSYS e.g. a SIGRTMIN set with a #define line because that number is subject to possible change later when the executable is run. This would have shown up a few years ago when both pthread libs were in use if an application compiled against the one pthread library was run on a system that had been rebooted with the other! | |
| Sep 16, 2014 at 10:03 | comment | added | cuonglm | Of course it varies base on system, but the term Linux does not supported is incorrect. You can refer this: cse.psu.edu/~dheller/cmpsc311/Lectures/Process-Control-Signals/…. Maybe we need a vereran who working with Linux long time ago to let us know what happen with signal 32, 33. Why aren't they documented. | |
| Sep 16, 2014 at 9:58 | comment | added | garethTheRed | @Gnouc - according to kill -l RTMIN starts at 34, not 32 as per you referenced document. This one says it starts at 33, but goes on to say that you shouldn't reference them by numbers as the numbers may vary depending on glibc threading implementation. | |
| Sep 16, 2014 at 9:50 | comment | added | cuonglm | Linux had signal 32 and 33. See: unixhelp.ed.ac.uk/CGI/man-cgi?signal+7, Real-time Signals section. | |
| Sep 16, 2014 at 9:41 | history | edited | garethTheRed | CC BY-SA 3.0 | added 100 characters in body |
| Sep 16, 2014 at 9:34 | history | answered | garethTheRed | CC BY-SA 3.0 |