Issue #22093 has been updated by alanwu (Alan Wu). Nice, and theoretically this enables using [pidfd_open(2)][1] underneath the abstraction to deal with pid recycling race conditions. (Whether that's a good idea is off topic.) [1]: https://www.man7.org/linux/man-pages/man2/pidfd_open.2.html ---------------------------------------- Feature #22093: Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork` https://bugs.ruby-lang.org/issues/22093#change-117480 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, process IDs returned by `Process.spawn` and `fork` are plain `Integer` objects. This works, but it makes common process-handling code slightly verbose and loses the opportunity to attach process-specific behavior to the returned value. For example: ```ruby pid = Process.spawn(...) _, status = Process.wait2(pid) if status.success? ... end ``` I propose introducing `Process::ID`, an Integer-like object representing a system process ID. `Process.spawn` and parent-side `Process.fork` would return `Process::ID`. `Process::ID` would provide convenience methods such as `#wait` and `#detach`. This allows process lifecycle code to be written more directly: ```ruby pid = Process.spawn(...) status = pid.wait if status.success? ... end ``` and, when the parent does not intend to wait explicitly: ```ruby pid = Process.spawn(...) pid.detach ``` ### Proposal Add `Process::ID`. `Process::ID` would: * represent a process ID * provide `#to_i` and `#to_int` * provide `#to_s` returning the decimal PID string * provide `#inspect`, like as `Process::Status` * provide `#pid` as a reader for the integer PID * provide `#wait`, returning `Process::Status` * provide `#detach`, returning `Process::Waiter` * support comparison with the underlying integer PID `Process.spawn` would return a `Process::ID` instead of an `Integer`. On platforms with `fork`, parent-side `fork` and `Process.fork` would return a `Process::ID`. The child side would keep the current behavior: `nil` for `fork` and `0` for `Process._fork`. `IO#pid` for `IO.popen` should also return the associated `Process::ID` when applicable. ### Rationale A process ID is currently represented by an `Integer`, but conceptually it is not just a number. It is a handle-like value used with process APIs such as `wait`, `waitpid`, `kill`, and `detach`. Providing a dedicated object makes common operations more discoverable and concise, while keeping compatibility through `#to_i`/`#to_int`. This is similar in spirit to `Process::Status`: process-related values can still expose primitive information, but the object itself can provide process-specific operations. `#wait` is useful when the parent wants to wait for the child and obtain its `Process::Status`: ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.wait.success? #=> true ``` `#detach` is useful when the parent intentionally does not want to wait for the child directly, but still wants to avoid leaving a zombie process: ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") waiter = pid.detach waiter.value #=> #<Process::Status: pid ... exit 0> ``` This is preferable to tying process cleanup to object finalization. A `dfree`/GC-based wait would make process reaping depend on GC timing and could unexpectedly consume the child status before explicit `Process.wait` code gets to it. `#detach` keeps the ownership transfer explicit. ### Compatibility This is a visible compatibility change because `Process.spawn(...).class` would become `Process::ID` instead of `Integer`. However, code that passes the PID to existing process APIs should continue to work because `Process::ID` provides `#to_int`. Potentially affected code is code that checks the exact class of the returned value, such as `pid.instance_of?(Integer)`, or uses type checks such as `Integer === pid`. Such code would need to treat the value as integer-like instead, for example by using `pid.to_i` when an actual `Integer` object is needed. For `Process._fork`, if it is overridden, `fork` should preserve the object returned by the overridden `_fork` on the parent side, as long as it is Integer-like. This keeps custom hooks compatible with code that returns PID wrapper objects. ### Examples ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.class #=> Process::ID pid.to_i #=> 12345 pid.to_s #=> "12345" pid.wait #=> #<Process::Status: pid 12345 exit 0> ``` ```ruby pid = fork { exit! true } pid.class #=> Process::ID pid.wait.success? #=> true ``` ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") thread = pid.detach #=> #<Process::Waiter:...> thread.value #=> #<Process::Status: pid ... exit 0> ``` ### Open questions * Should `Process::ID` include `Comparable`, or only define `<=>`? `<=>` is useful because PIDs have historically been `Integer` objects and are sometimes sorted simply to get a deterministic order, for example in `Process.waitall` results. The numeric ordering itself has no process-specific meaning, but preserving sortability is convenient. * Should `Process::ID#wait` accept the same integer flags as existing wait APIs, provide keyword arguments, or support both? Integer flags such as `Process::WNOHANG` are consistent with `Process.waitpid`, while keywords such as `nohang: true`, `untraced: true`, and `continued: true` may be more readable for a new convenience method. * Should `Process::ID#detach` simply be equivalent to `Process.detach(self)`? * Are there other process-related APIs that should return or preserve `Process::ID`? -- https://bugs.ruby-lang.org/

Issue #22093 has been updated by matz (Yukihiro Matsumoto). I see the appeal of `pid.wait` and `pid.detach`, but I'm not convinced. A PID is just a number, not a handle in the OS sense, so `Process::ID` would look handle-like without the safety a real handle (e.g. pidfd) would give. Unlike `Process::Status`, it would carry only a single integer and exist just to attach methods. PIDs are also returned by many other APIs (`Process.pid`, `ppid`, `waitpid`, PID files, etc.). Changing only `spawn`/`fork`/`IO#pid` is inconsistent, and changing all of them broadens the compatibility impact. For the modest ergonomic gain, I'd rather keep PIDs as `Integer` for now. Matz. ---------------------------------------- Feature #22093: Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork` https://bugs.ruby-lang.org/issues/22093#change-117551 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, process IDs returned by `Process.spawn` and `fork` are plain `Integer` objects. This works, but it makes common process-handling code slightly verbose and loses the opportunity to attach process-specific behavior to the returned value. For example: ```ruby pid = Process.spawn(...) _, status = Process.wait2(pid) if status.success? ... end ``` I propose introducing `Process::ID`, an Integer-like object representing a system process ID. `Process.spawn` and parent-side `Process.fork` would return `Process::ID`. `Process::ID` would provide convenience methods such as `#wait` and `#detach`. This allows process lifecycle code to be written more directly: ```ruby pid = Process.spawn(...) status = pid.wait if status.success? ... end ``` and, when the parent does not intend to wait explicitly: ```ruby pid = Process.spawn(...) pid.detach ``` ### Proposal Add `Process::ID`. `Process::ID` would: * represent a process ID * provide `#to_i` and `#to_int` * provide `#to_s` returning the decimal PID string * provide `#inspect`, like as `Process::Status` * provide `#pid` as a reader for the integer PID * provide `#wait`, returning `Process::Status` * provide `#detach`, returning `Process::Waiter` * support comparison with the underlying integer PID `Process.spawn` would return a `Process::ID` instead of an `Integer`. On platforms with `fork`, parent-side `fork` and `Process.fork` would return a `Process::ID`. The child side would keep the current behavior: `nil` for `fork` and `0` for `Process._fork`. `IO#pid` for `IO.popen` should also return the associated `Process::ID` when applicable. ### Rationale A process ID is currently represented by an `Integer`, but conceptually it is not just a number. It is a handle-like value used with process APIs such as `wait`, `waitpid`, `kill`, and `detach`. Providing a dedicated object makes common operations more discoverable and concise, while keeping compatibility through `#to_i`/`#to_int`. This is similar in spirit to `Process::Status`: process-related values can still expose primitive information, but the object itself can provide process-specific operations. `#wait` is useful when the parent wants to wait for the child and obtain its `Process::Status`: ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.wait.success? #=> true ``` `#detach` is useful when the parent intentionally does not want to wait for the child directly, but still wants to avoid leaving a zombie process: ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") waiter = pid.detach waiter.value #=> #<Process::Status: pid ... exit 0> ``` This is preferable to tying process cleanup to object finalization. A `dfree`/GC-based wait would make process reaping depend on GC timing and could unexpectedly consume the child status before explicit `Process.wait` code gets to it. `#detach` keeps the ownership transfer explicit. ### Compatibility This is a visible compatibility change because `Process.spawn(...).class` would become `Process::ID` instead of `Integer`. However, code that passes the PID to existing process APIs should continue to work because `Process::ID` provides `#to_int`. Potentially affected code is code that checks the exact class of the returned value, such as `pid.instance_of?(Integer)`, or uses type checks such as `Integer === pid`. Such code would need to treat the value as integer-like instead, for example by using `pid.to_i` when an actual `Integer` object is needed. For `Process._fork`, if it is overridden, `fork` should preserve the object returned by the overridden `_fork` on the parent side, as long as it is Integer-like. This keeps custom hooks compatible with code that returns PID wrapper objects. ### Examples ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.class #=> Process::ID pid.to_i #=> 12345 pid.to_s #=> "12345" pid.wait #=> #<Process::Status: pid 12345 exit 0> ``` ```ruby pid = fork { exit! true } pid.class #=> Process::ID pid.wait.success? #=> true ``` ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") thread = pid.detach #=> #<Process::Waiter:...> thread.value #=> #<Process::Status: pid ... exit 0> ``` ### Open questions * Should `Process::ID` include `Comparable`, or only define `<=>`? `<=>` is useful because PIDs have historically been `Integer` objects and are sometimes sorted simply to get a deterministic order, for example in `Process.waitall` results. The numeric ordering itself has no process-specific meaning, but preserving sortability is convenient. * Should `Process::ID#wait` accept the same integer flags as existing wait APIs, provide keyword arguments, or support both? Integer flags such as `Process::WNOHANG` are consistent with `Process.waitpid`, while keywords such as `nohang: true`, `untraced: true`, and `continued: true` may be more readable for a new convenience method. * Should `Process::ID#detach` simply be equivalent to `Process.detach(self)`? * Are there other process-related APIs that should return or preserve `Process::ID`? -- https://bugs.ruby-lang.org/