[llvm] Support: don't block signals around close if it can be avoided (PR #73009)

[Dimitry Andric via llvm-commits]

================
@@ -234,6 +234,25 @@ std::error_code Process::FixupStandardFileDescriptors() {
   return std::error_code();
 }
 
+// Close a file descriptor while being mindful of EINTR.
+//
+// On Unix systems closing a file descriptor usually starts with removing it
+// from the fd table (or an equivalent structure). This means any error
+// generated past that point will still result in the entry being cleared.
+//
+// Make sure to not bubble up EINTR as there is nothing to do in that case.
+// XXX what about other errors?
----------------
DimitryAndric wrote:

At least on FreeBSD, `EINTR` is a documented return value of `close(2)` (https://man.freebsd.org/cgi/man.cgi?query=close&sektion=2):

```text
     The close() system call will fail if:

     [EBADF]            The fd argument is not an active descriptor.

     [EINTR]            An interrupt was received.

     [ENOSPC]           The underlying object did not fit, cached data was
                        lost.

     [ECONNRESET]       The underlying object was a stream socket that was
                        shut down by the peer before all pending data was
                        delivered.

     In case of any error except EBADF, the supplied file descriptor is
     deallocated and therefore is no longer valid.
```

As noted, in all possible error cases, the file descriptor will no longer be valid afterwards. In case of `EINTR`, nothing more can be done anyway, so it does not make sense to retry, for example. So I guess the assumption is that the file will be closed in the background, somehow?

@mjguzik might know more about this logic :)

https://github.com/llvm/llvm-project/pull/73009