<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yep, they are definitely better, but... Oh well...<br>
</p>
<p>Off the top of my head, I don't immediately recall any DEC OS
that got into this 'maybe' kind of stuff. RSX and VMS certainly
got it right. Software interrupts on 36 bit machines are
reliable. Signals on Tops-20 are restricted to job context, but
they are reliable, too.<br>
</p>
<div class="moz-cite-prefix">
<hr width="100%" size="2">On 11/18/21 1:43 PM, Johnny Billquist
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e37ad255-d688-ad4a-1046-477d6ccc180e@softjar.se">Signals
is really a very poor design/implementation of what's called an
AST in RSX and VMS.
<br>
<br>
Whenever I have to deal with signals I just sit a wish I had RSX
around me instead.
<br>
<br>
But... One have to work with the tools provided. Admittedly,
signals have gotten better over the years. Nowadays they actually
are reliable... (But they still suck.)
<br>
<br>
Johnny
<br>
<br>
On 2021-11-18 19:38, Thomas DeBellis wrote:
<br>
<blockquote type="cite">Unix 5th? Gee, I guess I really must have
been doing it...
<br>
<br>
Doug is not the only person who has pointed this out; that
signals are not 'reliable'. I always thought some of the
behavior was pure baloney. If somebody sends you a signal, then
you should get it, period, end of story. And it shouldn't break
your current system call, either. We're not talking about
de-glitching a button.
<br>
<br>
I think the problem is really that what was implemented
almost--but not quite--filled a need, so it got used anyway.
There is a place for short, fast, conceptually simple to use
messages. All other kinds of IPC have setup overhead and most
have execution overhead. Shared memory comes to mind. Not
everything needs to be novel length if you are just alerting a
condition.
<br>
<br>
I was absolutely _delighted_ with reliable signals. I like them
even more when you can send a byte or two with the signal.
<br>
<br>
I stop listening when I hear anything about not depending on
them. I really do. It's a purist position.
<br>
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
On 11/18/21 1:04 PM, Dan Cross wrote:
<br>
<br>
The use of SIGHUP to reread a config file comes from, at
least, Unix 5th Edition. I suspect that the practice
originated with the `init` process (usually PID 1) which, on
receipt of SIGHUP, would reread the ttys file to figure out
what typewriters were attached to the system. Prior to that,
I suspect they'd have to reboot to add a new terminal to the
system, but things from first through 4th edition are not as
well preserved as 5th onwards, so its hard to tell.
<br>
<br>
By the time Berkeley was writing things like inetd, the
practice was well known. Does that make it a "standard?" Not
in any formal sense, but a daemon couldn't receive a SIGHUP in
the usual way an interactive process might, so piggybacking
some special meaning on it makes a certain amount of sense.
<br>
<br>
Has it fallen out of a favor? A bit. As Doug McIllroy put it
on the Unix Heritage Society list a few years ago, signal()
primarily existed to support SIGKILL, not as a principled
basis for IPC. It's racy and doing Real Work in the context
of an upcall from the kernel like a signal handler is fraught.
<br>
<br>
- Dan C.
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
On Thu, Nov 18, 2021 at 12:20 PM Dave
McGuire<a class="moz-txt-link-rfc2396E" href="mailto:mcguire@neurotica.com"><mcguire@neurotica.com></a> wrote:
<br>
<br>
<br>
Well, since the last release of SunOS (not Solaris) was
in 1994, and the last release of Ultrix was in 1995..
<br>
<blockquote type="cite">------------------------------------------------------------------------
<br>
On 11/18/21 12:12 PM, Thomas DeBellis wrote:
<br>
They do it _today_.
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>