[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spawn-pipe: close() EINTR handling

From: Pádraig Brady
Subject: Re: spawn-pipe: close() EINTR handling
Date: Wed, 03 Jul 2013 14:56:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]