[llvm] r219189 - Support: Don't call close again if we get EINTR

[Davide Italiano]

On Thu, Feb 19, 2015 at 6:44 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Most Unix-like operating systems guarantee that the file descriptor is
>> closed after a call to close(2), even if close comes back with EINTR.
>> For these systems, calling close _again_ will either do nothing or close
>> some other file descriptor open(2)'d by another thread. (Linux)
>
> Should we add an ifdef to avoid the sigmask dance on linux (and *BSD?)?
>

I can't comment for Linux, but, at least for FreeBSD, I'm not entirely
sure we should add this.
The reason why I'm opposed to the change is that #ifdef'ing we're
exposing an implementation detail that might change in the future.
FreeBSD tries to be conformant to POSIX, and unfortunately, in this
case the standard didn't do a good job at defining the semantic of
close in case of EINTR.

"If close() is interrupted by a signal that is to be caught, it shall
return -1 with errno set to [EINTR] and the state of fildes is
unspecified." http://pubs.opengroup.org/onlinepubs/009695399/functions/close.html

So, even if right now it looks like FreeBSD follows Linux in this
respect (although I'm not 100% sure), there's nothing that guarantees
the implementation to be changed in a way that the fd is leaked and
the standard isn't violated.  If this turns out to has a performance
impact, then it's probably OK to #ifdef, but I'm reluctant about
introducing this change if it's not a critical path.

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare