On Fri, May 31, 2024 at 10:29 PM Andrew Josey via austin-group-l at
The Open Group <[email protected]> wrote:
...
> Bug 1832: Add preadv() and pwritev()
> https://austingroupbugs.net/view.php?id=1832 OPEN
>
> We believe that preadv() and pwritev() should be cancellation points.
> Reading/writing to a file system across a network can certainly
> have unbounded delays.
Wait, what? My understanding for the last three decades, reinforced
by the various threads, was that *no* system with network filesystems
where regular file access was interruptible claimed conformance when
such were mounted/accessed and that there was no agreement to have the
standard permit such a thing given that only a tiny subset of
libraries and applications are written to handle that ("read/write of
a regular file may return EINTR or short-because-interrupted
read/write") robustly and subjecting that all applications would
simply Be Ignored.
Indeed, even the 202x draft 4 has a XBD 2.1.1 criteria 4:
----
The system may provide non-standard extensions. These are features
not required by
POSIX.1-2008 and may include, but are not limited to:
....
* Non-conforming file systems (for example, legacy file systems for which
_POSIX_NO_TRUNC is false, case-insensitive file systems, or
network file systems)
----
and the rationale still has mention of "read/write on a slow device
like a terminal" in XRAT B.2.4.4 paragraph 2:
----
The historical implementations of many functions defined by
POSIX.1-2024 are not interruptible,
but delay delivery of signals generated during their execution
until after they complete. This is
never a problem for functions that are guaranteed to complete in a
short (imperceptible to a
human) period of time. It is normally those functions that can
suspend a process indefinitely or
for long periods of time (for example, wait( ), pause( ),
sigsuspend( ), sleep( ), or read( )/write( ) on a
slow device like a terminal) that are interruptible. This permits
applications to respond to
interactive signals or to set timeouts on calls to most such
functions with alarm( ). Therefore,
implementations should generally make such functions (including
ones defined as extensions)
interruptible.
----
So, is this an intended statement by the austin group, that
applications that catch and return from interrupting signals must be
prepared for read/write of regular files to fail to return the
requested data?
In case it's not obvious, I find this surprising as an application
writer and distasteful as a system implementor.
"You can't interrupt this I/O with a signal, but cancelation *can*"
would be 1000% worse, btw.
Philip Guenther
