Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.arch
Subject: Re: Threads (was Re: MSI interrupts)
Date: Fri, 4 Apr 2025 01:44:04 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vsndh4$qn2$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <FoxHP.1477197$eNx6.766449@fx14.iad> <vsmfou$9n6$1@reader1.panix.com> <AvzHP.350389$sbY2.343252@fx40.iad>
Injection-Date: Fri, 4 Apr 2025 01:44:04 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="27362"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)

In article <AvzHP.350389$sbY2.343252@fx40.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <FoxHP.1477197$eNx6.766449@fx14.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>Dan Cross wrote:
>>>>[snip]
>>>> For instance, consider Unix/POSIX `open`: from an API
>>>> perspective this simply maps a symbolic file path name to a file
>>>> descriptor that can subsequently be used to perform IO on the
>>>> named file.  While it is well-known that the interface is
>>>> defined so that it can block opening some kinds of devices, for
>>>> example, some terminal devices until the line is asserted, that
>>>> is not the usual case, and noteably `open` does no IO on the
>>>> file itself.  So generally, most programs would expect that it
>>>> has no reason to block.
>>>
>>>The one case where open was a problem on traditional unix was
>>>for line printers.    The open of /dev/lp could block if the
>>>printer (on a centronics port) was not-ready.   And it was
>>>an uninterruptable block, even SIGKILL was blocked.
>>
>>I'd worry more about, say a pathname that requires traversing
>>NFS for one reason or another (symlinks, or just on a mounted
>>filesystem).  Nothing prevents an NFS server from becoming
>>inaccessible during a lookup.
>
>However, you can specify a soft mount rather than a hard mount
>to resolve that.

To kill the process, sure.  Still kinda sucks, though, from a
user experience point of view.  :-)

	- Dan C.