libc's rather poorly named kill(...) function returns when the specific signal is delivered. This means;
- For
SIGTERM, kill(...) may return before the target process has terminated. It may even ignore the signal.
- For
SIGKILL, the operation is handled by the kernel so generally by the time kill(...) returns the target will be terminated. However that isn't certain.
Both cases also may be rejected with EPERM (permission error).
Unfortunately checking process liveliness (e.g. with getpid on macOS or /proc/ on Linux) can't provide clarity here either, since process IDs are reused (not an issue on Windows from memory). Not to mention liveliness checks would need to contend with SIGTERM potentially doing nothing and both taking an undefined length of time to take effect.
The end result is Output::Killed is more of a Output::MaybeKilled.
libc's rather poorly namedkill(...)function returns when the specific signal is delivered. This means;SIGTERM,kill(...)may return before the target process has terminated. It may even ignore the signal.SIGKILL, the operation is handled by the kernel so generally by the timekill(...)returns the target will be terminated. However that isn't certain.Both cases also may be rejected with
EPERM(permission error).Unfortunately checking process liveliness (e.g. with
getpidon macOS or/proc/on Linux) can't provide clarity here either, since process IDs are reused (not an issue on Windows from memory). Not to mention liveliness checks would need to contend withSIGTERMpotentially doing nothing and both taking an undefined length of time to take effect.The end result is
Output::Killedis more of aOutput::MaybeKilled.