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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Robert Elz <kre%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 04:21:24 +0000

 > Date: Sun, 22 Dec 2024 07:49:25 +0700
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > 
 >     Date:        Sat, 21 Dec 2024 22:07:19 +0000
 >     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
 >     Message-ID:  <20241221220723.04ECB84E92%mail.netbsd.org@localhost>
 > 
 >   | Correction: Our current close() -- and probably all existing close()
 >   | implementations outside buggy proprietary Unix variants -- is not
 >   | compliant with POSIX.1-2024, because if some underlying I/O is
 >   | interrupted by a signal it can fail with EINTR even though the
 >   | descriptor is unconditionally closed.  That is now forbidden (emphasis
 >   | added):
 > 
 > Can it really?   I haven't looked at our implementation (kernel)
 > but it used to be the case that even if close() slept for some time,
 > (like waiting for tty output to drain) and a signal occurred, close()
 > would still return 0.
 
 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.  And I bet it will do this on most other operating systems too.
 
 > But if not, surely the simple change here is to make that happen, not
 > to work around it in libc - just have sys_close() never return EINTR.
 
 Would you like to volunteer to audit every device driver and file
 system, and every subroutine call they all make, to verify this?
 
 Gigantic waste of effort for a bad decision in POSIX which I'm
 inclined to say we should just flout because it's so bad.
 
 Current semantics -- which Linux, Solaris, and other BSDs already
 agree on -- is extremely simple and reliable: after close(d), d is
 closed.  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.
 
 If it was really necessary for some political reason not to simply
 endorse the simple rule `close() is final' (much like fclose() is
 already specified to be final), then POSIX could have added a simple
 feature macro like
 
 #define	_POSIX_CLOSE_IS_FINAL,
 
 or
 #define	_POSIX_CLOSE_IS_UNRELIABLE
 to accommodate the buggy proprietary Unix systems that motivated this
 whole mess.  Why should everyone else have to change their semantics
 of closing a file descriptor to accommodate their design bugs?