Re: [RFC PATCH 0/1] close(): stop exposing non-retryable EINTR

On Fri, 18 Sep 2026 14:56:39 +0200
Florian Weimer [off-list ref] wrote:

* Andy Lutomirski:

quoted

I think I mostly agree with your analysis except that I really don't
like the ENOSPC.  The kernel actually has the ability to commit to
having space for pending writes on an fd *without syncing*, then I
think that capability should be expose to userspace.  fsync is a
pretty poor alternative for code that just wants to make sure that, in
the absence of a bug, crash or physical failure, the data won't be
lost.  

It's something we might want to call from fflush.

As a replacement, dup3/close doesn't quite work because it releases
POSIX advisory locks on the original descriptor (as they are per
process, not per descriptor).

POSIX advisory locks are completely broken by design.
They just don't work for threaded processes at all.

Thread 1	thread 2	thread 3
open
lock
		open
		close
				open
				lock - succeeds

The same could easily happen if a single threaded process opens
the same file multiple times.

David

Thanks,
Florian