Re: Retrying close() after error on Linux !?

[Eric Blake]

On 03/14/2018 10:13 AM, Eric Blake wrote:
> On 03/14/2018 10:04 AM, Tim Rühsen wrote:
> > Hi,
> >
> >
> > just stumbled upon nonintr_close() in spawn-pipe.c which has this loop:
> >
> >    do
> >      retval = close (fd);
> >    while (retval < 0 && errno == EINTR);
> >
> >
> > Regarding the man page of libc, this shouldn't be done on certain
> > systems. E.g. it says the Linux kernel closes the file descriptor even
> > on EINTR. With the effect of possible race conditions in multi-threaded
> > code.
> >
> >
> > What do the experts here say ?
>
> Here's what POSIX has to say:
> http://austingroupbugs.net/view.php?id=529#c1200
>
> You are correct that retrying close (fd) is a bug in multi-threaded 
> programs.  It is better to leak the fd (on the few implementations that 
> leave fd open on EINTR failure) than to risk corrupting multithreaded 
> state.  If you are on a system that has posix_close() implemented (glibc 
> appears to not have done it yet, and I don't know if any other systems 
> have), then you are guaranteed that you can write race-free leak-free 
> code.  But until then, it's better to err on the side of safety, 
> especially since it was only a minority of systems that leave fd open on 
> EINTR failure.

I didn't offer my conclusion: I think the existence of nonintr_close() 
in gnulib is a bug, and should be removed.  It's better to assume Linux 
semantics (close ALWAYS destroys the fd, even when an error is reported) 
which is safe for multithreaded apps, than to assume that EINTR leaves 
the fd open (where assuming Linux semantics leaks on the few platforms 
that leave the fd open, but a leak is safer than multithreaded 
corruption when the wrong fd is closed on retry).

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org