Issue #19443 has been updated by akr (Akira Tanaka). I think detecting fork using PID is not a good idea. PID can conflict because PID is recycled. We can define Process.fork_level as follows. ``` % ruby -e ' class << Process attr_accessor :fork_level end Process.fork_level = 0 module ForkLevel def _fork pid = super Process.fork_level += 1 if pid == 0 pid end end class << Process; self end.prepend ForkLevel puts "parent_fork_level: #{Process.fork_level}" Process.wait(fork { puts "child_fork_level: #{Process.fork_level}" }) ' parent_fork_level: 0 child_fork_level: 1 ``` fork can be detected by comparing the result of Process.fork_level. This doesn't use PID (and getpid system call). So, it has no overhead by getpid and no problem with PID recycling. ---------------------------------------- Feature #19443: Cache `Process.pid` https://bugs.ruby-lang.org/issues/19443#change-101916 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- It's not uncommon for database client and similar network libraries to protect themselves from Process.fork by regularly checking Process.pid Until recently most libc would cache `getpid()` so this was a cheap check to make. However as of glibc version 2.25 the PID cache is removed and calls to `getpid()` always invoke the actual system call which significantly degrades the performance of existing applications. The reason glibc removed the cache is that some libraries were bypassing `fork(2)` by issuing system calls themselves, causing stale cache issues. That isn't a concern for Ruby as bypassing MRI's primitive for forking would render the VM unusable, so we can safely cache the PID. An example of the issue: https://github.com/rails/rails/issues/47418 Patch: https://github.com/ruby/ruby/pull/7326 -- https://bugs.ruby-lang.org/