Issue #19560 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. One of the purposes of `O_CLOFORK` seems to be to avoid thread race condition: if `fork` is called immediately after another thread opens a file, the file descriptor would unintentionally leak to a child process. To prevent this, it is essential that O_CLOFORK can be atomically specified at open, not after open. So the API `IO#close_on_fork=` is inappropriate for the purpose. Considering this, * @matz approved to define the constants provided by the OS: O_CLOFORK as `File::Constants::CLOFORK`, and FD_CLOFORK as `Fcntl::FD_CLOFORK`. * He did not approve an emulation layer for the case where the OS does not provide them. If it is absolutely necessary, more careful consideration and better API proposal will be required. --- Incidentally, O_CLOEXEC is set by default for open IOs. Therefore, a similar race condition issue should not occur. In other words, `IO#close_on_exec=` is not essential itself. It is just an auxiliary API for opt-out. It would be difficult to set O_CLOFORK by default because there are already many Ruby programs that pass IOs to a child process implicitly at `fork`. ---------------------------------------- Feature #19560: IO#close_on_fork= and IO#close_on_fork? https://bugs.ruby-lang.org/issues/19560#change-102784 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context Forking setups are extremely common in the Ruby ecosystem, as they remain the primary way to get parallelism with MRI. Generally speaking it works very well, however there are two main issues library authors and application owners need to be careful of: - Restarting threads - Closing inherited connections and other file descriptors. I believe we could make the second one much easier. ### O_CLOFORK A couple years ago, [a new flag was added to the POSIX spec: `O_CLOFORK`](https://austingroupbugs.net/view.php?id=1318). Similar to `O_CLOEXEC`, this file descriptor flag make it so the file descriptor is automatically closed upon forking. Unfortunately its support is relatively limited for now. It's supported on macOS and some relatively exotic unixes, but not in Linux nor most BSDs. [The feature was discussed on Linux mailing list](https://lore.kernel.org/lkml/20200525081626.GA16796@amd/T/#m5b8b20ea6…, but it seem to have encountered some strong opposition, so it's unclear if we can hope for it to be added. That said, I don't think it would be too hard for Ruby to shim this feature by closing all IOs with `close_on_fork?` right after fork. ### Ruby shim This can be implemented as a Ruby shim starting in Ruby 3.1 using the `Process._fork` callback ```ruby class IO def close_on_fork=(enabled) if enabled ::CloseIOOnFork::IOS[self] = true end @close_on_fork = enabled end def close_on_fork? @close_on_fork end end module CloseIOOnFork IOS = ObjectSpace::WeakMap.new def _fork pid = super if pid == 0 # child ::CloseIOOnFork::IOS.each_key do |io| io.close if io.close_on_fork? end end pid end end Process.singleton_class.prepend(CloseIOOnFork) rd, rw = IO.pipe rw.close_on_fork = true pid = fork do p rw.closed? # => true end Process.wait(pid) ``` ### Usage With such feature, many network client would mostly just need to set this flag on their sockets, and just properly handle unexpectedly closed connections, which most already do. -- https://bugs.ruby-lang.org/

Issue #19560 has been updated by Dan0042 (Daniel DeLorme). If it's possible to open a file with CLOFORK, it should also be possible to answer the question "has this file been opened with CLOFORK?" Would that be done via `IO#close_on_fork?` or maybe some `flags & CLOFORK` ? ---------------------------------------- Feature #19560: IO#close_on_fork= and IO#close_on_fork? https://bugs.ruby-lang.org/issues/19560#change-102808 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context Forking setups are extremely common in the Ruby ecosystem, as they remain the primary way to get parallelism with MRI. Generally speaking it works very well, however there are two main issues library authors and application owners need to be careful of: - Restarting threads - Closing inherited connections and other file descriptors. I believe we could make the second one much easier. ### O_CLOFORK A couple years ago, [a new flag was added to the POSIX spec: `O_CLOFORK`](https://austingroupbugs.net/view.php?id=1318). Similar to `O_CLOEXEC`, this file descriptor flag make it so the file descriptor is automatically closed upon forking. Unfortunately its support is relatively limited for now. It's supported on macOS and some relatively exotic unixes, but not in Linux nor most BSDs. [The feature was discussed on Linux mailing list](https://lore.kernel.org/lkml/20200525081626.GA16796@amd/T/#m5b8b20ea6…, but it seem to have encountered some strong opposition, so it's unclear if we can hope for it to be added. That said, I don't think it would be too hard for Ruby to shim this feature by closing all IOs with `close_on_fork?` right after fork. ### Ruby shim This can be implemented as a Ruby shim starting in Ruby 3.1 using the `Process._fork` callback ```ruby class IO def close_on_fork=(enabled) if enabled ::CloseIOOnFork::IOS[self] = true end @close_on_fork = enabled end def close_on_fork? @close_on_fork end end module CloseIOOnFork IOS = ObjectSpace::WeakMap.new def _fork pid = super if pid == 0 # child ::CloseIOOnFork::IOS.each_key do |io| io.close if io.close_on_fork? end end pid end end Process.singleton_class.prepend(CloseIOOnFork) rd, rw = IO.pipe rw.close_on_fork = true pid = fork do p rw.closed? # => true end Process.wait(pid) ``` ### Usage With such feature, many network client would mostly just need to set this flag on their sockets, and just properly handle unexpectedly closed connections, which most already do. -- https://bugs.ruby-lang.org/