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: Thu, 3 Apr 2025 17:16:14 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vsmfou$9n6$1@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <vsjclj$mtp$1@reader1.panix.com> <vsm6ul$tmpt$1@dont-email.me> <FoxHP.1477197$eNx6.766449@fx14.iad>
Injection-Date: Thu, 3 Apr 2025 17:16:14 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="9958"; 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 <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.

	- Dan C.