This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.

On Thu, Dec 05, 2013 at 03:50:09PM -0500, David Miller wrote:
> From: Rich Felker <>
> Date: Thu, 5 Dec 2013 15:11:26 -0500
> > If EINTR from close essentially doesn't show up in the wild on Linux,
> > I think the proposed change in glibc to replace it with EINPROGRESS
> > would essentially be just a safety against (dangerous!) double-close
> > bugs in correct POSIX applications due to strange devices slipping an
> > EINTR through. I'm still strongly in favor of adding it (or a
> > replacement with 0/success).
> At one time many years ago there was a path in the kernel that
> returned an error from close and it broke so many things.  Even emacs
> crashed.
> The widespread overwhelming belief is that close() is just going
> to always succeed, and there is more harm than good from signalling
> errors at all from that function.

Obviously close can't return 0 all the time; it has to return EBADF if
the argument is not a valid file descriptor. But otherwise it should
always "succeed". The nicest possible behavior on the kernel side
would be if the kernel guaranteed that close can't even enter an
interruptible sleep, performing any device-specific flush/close
operations asynchronously without the application having to worry
about it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]