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

[David Laight]

On Fri, 18 Sep 2026 14:56:39 +0200
Florian Weimer <fweimer@xxxxxxxxxx> wrote:

> * Andy Lutomirski:
> 
> > 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
> 
>