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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
