You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Reconsider guarantees of `Pid` and refactor
1. `Pid` and `RawPid` use `NonZeroI32` and `i32` now. `Pid` are
guaranteed to be in range `1..=i32::MAX`.
Notice that pid range should be enforced for all APIs, and negative
values are exploited by Linux for different functionalities (eg, kill(2)
a process group instead of a process). We should validate that range to
prevent accidental misfunction, no matter for `i32` or `u32`.
So here we consistently use a wrapped `i32` for both linux_raw and libc
backend. Two constructor `Pid::from_raw{,_unchecked}` are provided to
either do or bypass the check. These APIs also simplify code a lot.
2. `Pid::from_raw_nonzero` is removed.
As mentioned in (1), the range guarantee is stricter now and only the
nonzero property cannot help much.
This is a breaking change.
3. `Pid::from_raw` is safe now.
We are not possible to make any guarantee for an arbitrary non-children
pid at all, and an invalid pid causes nothing more than a logic error.
But since we use `NonZeroI32` internally, `Pid::from_raw_unchecked` is
still unsafe.
* Fix typo in doc of `Pid::is_init`
* Clean up unnecessary `unsafe` and `unwrap`
* Remove `unsafe` for `Pid::from_raw` on FreeBSD and Darwin
* Disable debug_assert in `Pid::from_raw_unchecked` due to MSRV
* Re-enable `debug_assert!` in a const fn, now that our MSRV is 1.63.
* Remove `RawNonZeroPid`.
* Make `get_reaper_status`'s `pid` result optional.
The documentation for the field is qualified with "if there are any
descendants". It appears if there are no descendents, the `rs_pid`
field is -1. Check for this case, to avoid trying to convert -1 to
a `Pid`.
---------
Co-authored-by: Dan Gohman <[email protected]>
0 commit comments