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

[Mateusz Guzik via llvm-commits]

mjguzik wrote:

It's not a hot path, it is just an example of numerous artificial problems (at least in terms of syscalls which get invoked).

Here is something else to give you a flavor:
```
91053: access("a.out",F_OK)                      = 0 (0x0)
91053: fstatat(AT_FDCWD,"a.out",{ mode=-rwxr-xr-x ,inode=57547,size=9664,blksize=9728 },0x0) = 0 (0x0)
91053: openat(AT_FDCWD,"a.out",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
91053: fstatat(AT_FDCWD,"a.out",{ mode=-rwxr-xr-x ,inode=57547,size=9664,blksize=9728 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
91053: fstatat(AT_FDCWD,"a.out",{ mode=-rwxr-xr-x ,inode=57547,size=9664,blksize=9728 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
91053: unlink("a.out")                           = 0 (0x0)

/* here goes stuff not even dealing with the above */
91053: mmap(0x803cc5000,2101248,PROT_READ|PROT_WRITE,MAP_STACK,-1,0x0) = 35211739136 (0x832c88000)
91053: mprotect(0x832c88000,4096,PROT_NONE)      = 0 (0x0)
91053: thr_new(0x8246c8a00,0x68)                 = 0 (0x0)
91053: <new thread 655536>
91053: sigfastblock(0x1,0x31ba9a812e38)          = 0 (0x0)
91053: _umtx_op(0x31ba9a8130c8,UMTX_OP_NWAKE_PRIVATE,0x1,0x0,0x0) = 0 (0x0)
91053: _umtx_op(0x8275ec028,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) = 0 (0x0)
/* and back to a.out */

91053: fstatat(AT_FDCWD,"a.out",0x8246c8858,0x0) ERR#2 'No such file or directory'
91053: close(3)                                  = 0 (0x0)
```

For example not only thera are clearly avoidable stat calls, the last one comes after llvm unlinked the file.

And so on. truss/strace -f output is really bad.

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