On 07/03/2013 01:46 PM, Eric Blake wrote: > On 07/03/2013 05:26 AM, Pádraig Brady wrote: >> So I was reading http://austingroupbugs.net/view.php?id=529 >> which states on Linux that one shouldn't retry close() after EINTR >> as the descriptor is already closed in that case >> and another thread could reuse the descriptor >> which a retried close() would close erroneously. > > If Linux ever returns EINTR on close(), that's a bug in Linux. While > researching the resolution to > http://austingroupbugs.net/view.php?id=529, I asked Linux kernel > developers if EINTR is even possible, and no one could point to a > definitive code path with an EINTR. >> >> That suggests that the following code in spawn-pipe is problematic? >> Should be remove the retry, and/or do we need to otherwise >> handle the SIGSTOP case? >> >> thanks, >> Pádraig. >> >> /* EINTR handling for close(). >> These functions can return -1/EINTR even though we don't have any >> signal handlers set up, namely when we get interrupted via SIGSTOP. */ > > That may be a true statement for OS's that return EINTR on close > failure, but my understanding Linux is not such a platform. All known > platforms that have EINTR failure (basically HPUX) also leave the fd open. > >> >> static int >> nonintr_close (int fd) >> { >> int retval; >> >> do >> retval = close (fd); >> while (retval < 0 && errno == EINTR); >> >> return retval; >> } >> #define close nonintr_close >> > > My assumption is that the gnulib code is safe as-is, because the EINTR > check is dead code on Linux.
OK maybe the gnulib code is safe because the close() is only done on pipes, but I think the EINTR issue is definitely there with sockets. For example see: http://alobbs.com/post/54503240599/close-and-eintr thanks, Pádraig.
