

Most operating systems have implemented realtime signals incorrectly - rzezeski
http://zinascii.com/2014/crossed-signals.html

======
JoeAltmaier
Since 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...

~~~
noselasd
There's test suites:
[http://www.opengroup.org/testing/downloads.html](http://www.opengroup.org/testing/downloads.html)
, though I don't know what they cover - posix is highly componentized.

------
apaprocki
Happy (if you could call it that!) to report AIX 7.1 works correctly :)

    
    
        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
    

Solaris 11 still appears backwards:

    
    
        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 2

------
rdtsc
I 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?

~~~
pjc50
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/](http://www.viva64.com/en/a/0083/)

"Move fast and break things" is not a great motto for automotive control
software.

~~~
amelius
How about games, where, e.g., sound effects have a maximum acceptable delay
w.r.t. the physics that generates them?

~~~
justincormack
Signals are not a great mechanism anyway, it turned out.

------
fotoetienne
Minor nitpick: The HP-UX version that you are likely referring to is HP-UX 11i
which is also known as HP-UX 11.11. 11.11i is not an HP-UX version number.

As a point of curiosity, this version is still employed in many nuclear
plants.

------
pjc50
Conclusion: 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)

~~~
apaprocki
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.

------
acqq
> 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?

~~~
rzezeski
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.

------
aidenn0
Here's another POSIXism that everybody gets wrong: command lookup for sh;
follow this algorithm for executing a command with no slashes, consider what
would happen if "echo" is not in your path. Try it out on any shell and see
that it just runs the "echo" builtin despite it being required to return 127.

Text below taken from:
[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01)

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.

~~~
Borealid
Quoting from your post:

"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.

~~~
aidenn0
"special built-in utilities" are specifically listed elsewhere. echo is not
among them:

[http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14)

~~~
Borealid
A lawyerly reading still permits echo to qualify as a special built-in
utility.

Two relevant excerpts: "The following "special built-in" utilities shall be
supported in the shell command language ..."

"... The term "built-in" implies that the shell can execute the utility
directly and does not need to search for it. An implementation may choose to
make any utility a built-in; however, the special built-in utilities described
here differ from regular built-in utilities ..."

(the two differences are irrelevant to this discussion as they do not mention
PATH resolution behaviors)

These quotes taken together do not preclude the shell adding a built-in
utility and assigning it the "special" status. The standard does not say that
only the listed utilities are special; it says that the listed utilities shall
be special. Adding a normal built-in utility (not "special") not on the list
is explicitly condoned.

It is my belief that echo being a "special built-in utility" and thus having
magic PATH behavior is POSIX compliant, although the standard is not 100%
clear on this.

