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...
RT sig 50 received with sival 0
RT sig 50 received with sival 1
RT sig 50 received with sival 2
RT sig 51 received with sival 0
RT sig 51 received with sival 1
RT sig 51 received with sival 2
RT sig 52 received with sival 0
RT sig 52 received with sival 1
RT sig 52 received with sival 2
RT sig 43 received with sival 0
RT sig 43 received with sival 1
RT sig 43 received with sival 2
RT sig 42 received with sival 0
RT sig 42 received with sival 1
RT sig 42 received with sival 2
RT sig 41 received with sival 0
RT sig 41 received with sival 1
RT sig 41 received with sival 2So anyone used real-time signals and why did you pick them instead of something else?
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.
> 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:
As a point of curiosity, this version is still employed in many nuclear plants.
(I've used them once to workaround per-thread signal masking not behaving well for non-realtime signals)
Do you remember what the misbehavior was? I ask because I actually work with these kinds of things.
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?
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.
Text below taken from: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked.
If the command name matches the name of a function known to this shell, the function shall be invoked as described in Function Definition Command. If the implementation has provided a standard utility in the form of a function, it shall not be recognized at this point. It shall be invoked in conjunction with the path search in step 1d.
If the command name matches the name of a utility listed in the following table, that utility shall be invoked.
alias bg cd command
false fc fg getopts
jobs kill newgrp pwd
read true umask unalias
wait
Otherwise, the command shall be searched for using the PATH environment variable as described in XBD Environment Variables :
If the search is successful:
<snip>
If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.
"If the command name matches the name of a special built-in utility, that special built-in utility shall be invoked."
Let echo be a "special built-in utility", and sh is compliant.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...
If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search.
I think the logic behind this was to ensure that as shells add more built-ins scripts that depend on an executable failing when not in the path won't break.