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
