Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most operating systems have implemented realtime signals incorrectly

zinascii.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Most operating systems have implemented realtime signals incorrectly

#11

Post by 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

Re: Most operating systems have implemented realtime signals incorrectly

#12

Post by 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...

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:

If the search is unsuccessful, the command shall fail with an exit status of 127 and the shell shall write an error message.

Re: Most operating systems have implemented realtime signals incorrectly

#13

Post by riffraff »

rdtsc wrote: post #6

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?

I remember studying POSIX message queues in the first OS class I took at the university. Nowadays, I have no I idea if anybody is actually using them.

Re: Most operating systems have implemented realtime signals incorrectly

#14

Post by [deleted] »

riffraff wrote: post #13
rdtsc wrote: post #6

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?

I remember studying POSIX message queues in the first OS class I took at the university. Nowadays, I have no I idea if anybody is actually using them.

[deleted]

Re: Most operating systems have implemented realtime signals incorrectly

#16

Post by EdiX »

aidenn0 wrote: post #12

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... If the command name matches…

Step 1.d.i.a:

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.

Re: Most operating systems have implemented realtime signals incorrectly

#17

Post by Borealid »

aidenn0 wrote: post #12

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... If the command name matches…

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.

Re: Most operating systems have implemented realtime signals incorrectly

#18

Post by amelius »

pjc50 wrote: post #8
rdtsc wrote: post #6

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?

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 sof…

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

Re: Most operating systems have implemented realtime signals incorrectly

#19

Post by gaius »

pjc50 wrote: post #8
rdtsc wrote: post #6

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?

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 sof…

Well, any sort of process control too (as in, controlling an assembly line or a chemical plant).

Re: Most operating systems have implemented realtime signals incorrectly

#20

Post by justincormack »

amelius wrote: post #18
pjc50 wrote: post #8

Earlier quoted context omitted.

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 sof…

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

Signals are not a great mechanism anyway, it turned out.
Post reply on HN