Most operating systems have implemented realtime signals incorrectly
1–10 of 25 posts
Re: Most operating systems have implemented realtime signals incorrectly
#2Since they all do such a spectacular job of delivering different (buggy) results, I have to believe support was 'roll-your-own' on each platform. There's no reference implementation of POSIX features? No test cases? I guess there are now.
I helped deliver the 1st POSIX implementation, the year it was specified, on an old real-time OS called CTOS (BTOS if you bought it from Burroughs/Unisys). I wonder if we got it right...
Re: Most operating systems have implemented realtime signals incorrectly
#3> The kernel delivers the the signals in the correct order only to have userland invert them on the stack.
So does it mean that it's not a kernel bug at all? Just the libc? Then it's not surprising that different kernels, all using the same libc, have the same bug?
Re: Most operating systems have implemented realtime signals incorrectly
#4> The kernel delivers the the signals in the correct order only to have userland invert them on the stack. So does it mean that it's not a kernel bug at all? Just the libc? Then it's not surprising that different kernels, all using the same libc, have the same bug?
These different kernels do not use the same libc. In particular, BSD derivatives are using a BSD libc, while Linux and friends are using glibc (or some cousin). I'm not certain which libc the others are using, but they are likely separate forks as well.
Re: Most operating systems have implemented realtime signals incorrectly
#5> The kernel delivers the the signals in the correct order only to have userland invert them on the stack. So does it mean that it's not a kernel bug at all? Just the libc? Then it's not surprising that different kernels, all using the same libc, have the same bug?
All kernels do not use the same libc. In fact, Linux is different in the fact that it doesn't ship a libc with the kernel. Illumos, the OS I investigated, goes by the philosophy that you _have_ to ship libc with your kernel, and thus they have their own libc.
My diagnosis for Illumos may not hold up on other OSs, they may invert priority for other reasons. In any case the spec is fairly clear that a signal is considered delivered when the "appropriate action" is taken. In this case the appropriate action is to invoke the user's handler, which is above libc on the stack.
Finally, in case you missed it, I witnessed 4 unique orderings across the systems I tested. They were not the same across the board.
Re: Most operating systems have implemented realtime signals incorrectly
#6I have seen realtime signals before but never quite know what the intended use of them would be. They are relegated in my head to the same category as POSIX message queues -- remember for trivia question purposes.
So anyone used real-time signals and why did you pick them instead of something else?
Re: Most operating systems have implemented realtime signals incorrectly
#7Conclusion: hardly anyone uses realtime signals, and if they do they have no way of testing that they actually get the desired preemption behavior.
(I've used them once to workaround per-thread signal masking not behaving well for non-realtime signals)
Re: Most operating systems have implemented realtime signals incorrectly
#8I have seen realtime signals before but never quite know what the intended use of them would be. They are relegated in my head to the same category as POSIX message queues -- remember for trivia question purposes. So anyone used real-time signals and why did you pick them instead of something else?
The intended use case is people trying to write realtime systems - that is, systems with a latency guarantee, like antilock brakes or flight control systems - in UNIX.
However, no sensible person would write such a thing in a general-purpose multi-user operating system. Realtime is hard, see the Toyota mess: http://www.viva64.com/en/a/0083/
"Move fast and break things" is not a great motto for automotive control software.
Re: Most operating systems have implemented realtime signals incorrectly
#9I have seen realtime signals before but never quite know what the intended use of them would be. They are relegated in my head to the same category as POSIX message queues -- remember for trivia question purposes. So anyone used real-time signals and why did you pick them instead of something else?
According to POSIX.1b RT signals are used for other features defined in .1b. An excerpt from "POSIX.4 Programmers Guide":
> So far, we've talked about real-time signals sent by the sigqueue function. However, most POSIX.4 signals are sent as a result of three other facilities in POSIX.4. We'll cover these facilities in detail in their own chapters, but for now, you need to know that realtime signals can be generated as a result of expiration of a POSIX.4 timer, completion of asynchronous I/O, and by arrival of a message on an empty message queue.
Linux reserves 2-3 RT signals for use in its threading library:
Re: Most operating systems have implemented realtime signals incorrectly
#10Conclusion: hardly anyone uses realtime signals, and if they do they have no way of testing that they actually get the desired preemption behavior. (I've used them once to workaround per-thread signal masking not behaving well for non-realtime signals)
I would not have that take-away.. I would instead say that probably most of the users of the signal features described in the article are not concerned with making their code cross-platform.