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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> 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?