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

[Bruno Haible]

Hi Eric,

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

Glad to see that this has been addressed in POSIX.

I definitely saw the need to handle EINTR with various system calls (read,
write, close) on early versions of Solaris, when a signal handler for SIGINT
is installed and the user presses Ctrl-C.

The types of fd on which this occurred were likely ttys and possibly NFS
mounted files (don't remember exactly).

> It is better to leak the fd (on the few implementations that 
> leave fd open on EINTR failure) than to risk corrupting multithreaded 
> state.

No, not in all situations. When fd is a tty and you spawn a process that
is intended to communicate through a pipe, the usual end-of-stream handling
(EOF for reading, SIGPIPE for writing) will NOT happen if there is an fd
that has accidentally been left open. Therefore in spawn_pipe it is essential
that close() really closes what was intended.

I think we'll need to fall back to a #if based on platforms.

Bruno