Re: kern/58929: POSIX.1-2024 compliance: posix_close, POSIX_CLOSE_RESTART

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58929; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58929: POSIX.1-2024 compliance: posix_close, POSIX_CLOSE_RESTART
Date: Sun, 22 Dec 2024 11:50:26 +0700

     Date:        Sun, 22 Dec 2024 04:21:24 +0000
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20241222042128.8CA8185574%mail.netbsd.org@localhost>
 
   | Mount an nfs volume with `-i', open a file, unplug the network, write
   | to the file, close it, and hit ^C.  I bet close(2) will fail with
   | EINTR.
 
 It quite likely might, but it shouldn't.   EINTR is supposed to mean
 "do it again (if you want to)" - or more verbosely "While waiting to
 perform the operation you requested, a signal was sent to you.  Rather
 than keep that signal pending for perhaps a long time, we are abandoning
 your request, so you can process the signal.  After you have done that,
 should you still desire to perform this operation, repeat the call".
 
 Note that in cases like read(), write() etc, once a single byte has
 been transferred to/from a device (or network connection, etc) EINTR
 is no longer allowed, rather the call returns successfully with a
 short count - as simply repeating the call would result in lost/duplicated
 data.   EINTR happens only when the system call hasn't changed the
 state of the process, or should.
 
   | Would you like to volunteer to audit every device driver and file
   | system, and every subroutine call they all make, to verify this?
 
 No, nor do I need to.   I just looked at the close system call, and
 it does, as you say, and has more or less been true forever:
 
   | Current semantics -- which Linux, Solaris, and other BSDs already
   | agree on -- is extremely simple and reliable: after close(d), d is
   | closed.
 
 Exactly.   The close has happened.   So why are we returning EINTR ?
 
 That makes no sense at all.
 
   | No ifs or buts about it.  POSIX.1-2024 semantics is
   | hopelessly confusing for users and implementors alike, and is
   | incompatible with the vast majority of existing practice -- a mistake.
 
 It is attempting (like almost always) to inform users of what they
 may encounter, while still making the system robust.
 
 For any system with the "close is final" semantic, it is really very
 simple, just don't ever return EINTR (which would indicate the close
 didn't occur) and all is good.
 
   | Why should everyone else have to change their semantics
   | of closing a file descriptor to accommodate their design bugs?
 
 No-one has to change (almost) anything, except to avoid returning an
 obviously bogus error code.
 
 What do you expect application code that receives EINTR from close()
 to do with that information as things are currently?
 
 kre