refactor: remove child ownership from Exit filter

[rogercoll]

These change loose the BSD systems API when creating an Exit struct. At the moment, the Exit struct takes ownership of the Child struct and not publicly exporting it, preventing being able to call Child's methods.

The Exit struct is primarily used to wait for a child process termination using the reactor's registration functionality. The Registration uses the polling crate to perform the async wait. The polling only requires a PID, thus these changes removes the child ownership from the package in favor of just providing a PID number.

This will ease the development of the async-process for BSD systems: smol-rs/async-process#49 (comment)

[rogercoll]

Any clue why the CI is failing?

   /home/runner/.cargo/bin/cargo audit --json --file ./Cargo.lock
  error: not found: Couldn't load ./Cargo.lock
  Caused by:
    -> I/O operation failed: I/O operation failed: entity not found

Does it require the Cargo.lock file from now on?

[notgull]

I'd like to avoid a breaking change, can we make this a new method instead?

[rogercoll]

Good point, a new from_pid constructor added in 4308464 instead. I made it unsafe to propagate the safety statement when creating a polling process from a pid.

Wdyt?

[notgull]

I don't think it actually needs to be unsafe? While it's unsafe for FDs, PIDs are allowed to be racy IIRC

[rogercoll]

The main reason behind the unsafe was to propagate the "safety" statement defined in the polling process (and used by the reactor):

/// Create a `Process` from a PID.
    ///
    /// # Safety
    ///
    /// The PID must be tied to an actual child process.
    pub unsafe fn from_pid(pid: std::num::NonZeroI32, ops: ProcessOps) -> Self {
        Self {
            pid: unsafe { rustix::process::Pid::from_raw_unchecked(pid.get()) },
            ops,
            _lt: PhantomData,
        }
    }

With the new Exit status API, the struct can be crated for any given u32 value, thus the possibility of not being tied to an actual child process (differently than child.id()). This is the error when the provided pid is not attached to a process:

Error: Os { code: 3, kind: Uncategorized, message: "No such process" }

[rogercoll]

Given that with the new from_pid it lets the user provide any PID value, do you still think the unsafe guidance is not needed?

Thanks for your feedback.

[notgull]

Hmm, keep it as unsafe for now. It's been a while since I've reviewed kqueue's implementation, I trust my past self more in that regards.

[notgull]

LGTM aside from one minor nitpick

[notgull]

I would prefer keeping the example simple.

[rogercoll]

sgtm 610773a

[notgull]

I'll try to push this as a release this weekend