[HECnet] PyDECnet setup

[Thomas DeBellis]

Yep, they are definitely better, but...  Oh well...

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.

------------------------------------------------------------------------
On 11/18/21 1:43 PM, Johnny Billquist wrote:
> Signals is really a very poor design/implementation of what's called 
> an AST in RSX and VMS.
>
> Whenever I have to deal with signals I just sit a wish I had RSX 
> around me instead.
>
> 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.)
>
>   Johnny
>
> On 2021-11-18 19:38, Thomas DeBellis wrote:
>> Unix 5th?  Gee, I guess I really must have been doing it...
>>
>> 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.
>>
>> 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.
>>
>> I was absolutely _delighted_ with reliable signals.  I like them even 
>> more when you can send a byte or two with the signal.
>>
>> I stop listening when I hear anything about not depending on them.  I 
>> really do.  It's a purist position.
>>
>>> ------------------------------------------------------------------------ 
>>>
>>> On 11/18/21 1:04 PM, Dan Cross wrote:
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>          - Dan C.
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> On Thu, Nov 18, 2021 at 12:20 PM Dave 
>>>> McGuire<mcguire at neurotica.com>  wrote:
>>>>
>>>>
>>>>     Well, since the last release of SunOS (not Solaris) was in 
>>>> 1994, and the last release of Ultrix was in 1995..
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> On 11/18/21 12:12 PM, Thomas DeBellis wrote:
>>>>> They do it _today_.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211118/8d05031b/attachment-0001.htm>