[ruby-core:112471] [Ruby master Feature#19443] Cache `Process.pid`

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/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/