Issue #21704 has been updated by matz (Yukihiro Matsumoto). I am fine with exposing this API for fiber scheduler implementations; the use case (io_uring based `process_wait`) is legitimate. Regarding the name, I slightly prefer `rb_process_status()` over `rb_process_status_for()`. The `_for` suffix does not add much information here. That said, this is in fiber scheduler territory, so I leave the final decision (name and exact signature) to @ioquatix. Matz. ---------------------------------------- Feature #21704: Expose `rb_process_status_for` to C extensions https://bugs.ruby-lang.org/issues/21704#change-117999 * Author: noteflakes (Sharon Rosner) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- (Previously `rb_process_status_new`) A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_for` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/