Support: Don't call close again if we get EINTR
authorDavid Majnemer <david.majnemer@gmail.com>
Tue, 7 Oct 2014 05:48:40 +0000 (05:48 +0000)
committerDavid Majnemer <david.majnemer@gmail.com>
Tue, 7 Oct 2014 05:48:40 +0000 (05:48 +0000)
commit220c5ca8f487082d12122f6e440e08ca3518e4de
tree027d2728ad080db970764b3e1120573886a8ff06
parent61c4e41480ef81f4449acc8604efdcd1c26607b2
Support: Don't call close again if we get EINTR

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)

However, some operating systems do not have this behavior.  They require
at least another call to close(2) before guaranteeing that the
descriptor is closed. (HP-UX)

And some operating systems have an unpredictable blend of the two
behaviors! (xnu)

Avoid this disaster by blocking all signals before we call close(2).
This ensures that a signal will not be delivered to the thread and
close(2) will not give us back EINTR.  We restore the signal mask once
the operation is done.

N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR
because signals always get delivered to dedicated signal handling
threads.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219189 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Support/Process.h
lib/Support/Unix/Process.inc
lib/Support/Windows/Process.inc
lib/Support/raw_ostream.cpp