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

21–25 of 25 posts

Re: Most operating systems have implemented realtime signals incorrectly

#21

Post by aidenn0 »

Borealid wrote: post #17
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.

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

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

Re: Most operating systems have implemented realtime signals incorrectly

#22

Post by aidenn0 »

EdiX wrote: post #16
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.

1.d.i only happens if the search in PATH is successful.

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.

Re: Most operating systems have implemented realtime signals incorrectly

#23

Post by noselasd »

JoeAltmaier wrote: post #2

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

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

Re: Most operating systems have implemented realtime signals incorrectly

#24

Post by javert »

pjc50 wrote: post #7

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)

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

Re: Most operating systems have implemented realtime signals incorrectly

#25

Post by Borealid »

aidenn0 wrote: post #21
Borealid wrote: post #17

Earlier quoted context omitted.

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.

"special built-in utilities" are specifically listed elsewhere. echo is not among them: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

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.

Post reply on HN