After #24034 lands we will be setting CLOEXEC on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking.

Many platforms have methods of creating CLOEXEC file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of fd.set_cloexec() that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7.

• File::open - this should specify the O_CLOEXEC flag. This flag was added in linux 2.6.23 and appears to exist on OSX 10.7. Atomically open files with O_CLOEXEC where possible #27971
• Socket::new - this should be specify the SOCK_CLOEXEC flag in the type argument (second). This flag was only added in linux 2.6.27 and does not exist on OSX. Finish atomically setting CLOEXEC for fds created on Unix #31417
• Socket::accept - this should be replaced with a call to accept4. This system call was only added in linux 2.6.28 and does not exist on OSX. Finish atomically setting CLOEXEC for fds created on Unix #31417
• Socket::duplicate - this should be replaced with dup3 (linux 2.6.27, not on OSX) or F_DUPFD_CLOEXEC (linux 2.6.24, appears to exist on OSX 10.7). Atomically set CLOEXEC on duplicated sockets #27980
• anon_pipe - this could be replaced with pipe2 on linux 2.6.27 and perhaps socketpair on OSX (not confirmed). Finish atomically setting CLOEXEC for fds created on Unix #31417

The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).