Issue #19443 has been updated by byroot (Jean Boussier).
PID can conflict because PID is recycled.
I don't think it's a big concern for this use case, even with PID recycling, the PID of the child can't possibly be the same than the parent. So unless you fork several time without ever triggering the check, you can't possibly be by this.
We can define Process.fork_level as follows.
Yes, on Ruby 3.1+ we can decorate `Process._fork` for that purpose. I already submitted PRs to major libraries to do that when possible, however: - It doesn't work for `Process.daemonize` (not a big deal, but still) - There is a long tail of existing code doing this, and fixing it all may take a very long time. Also, regardless of what `Process.pid` is used for, if we can make it 5x faster with extremely little code, and as far as I can tell no downsides, why shouldn't we? ---------------------------------------- Feature #19443: Cache `Process.pid` https://bugs.ruby-lang.org/issues/19443#change-101918 * 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/