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
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.
The text was updated successfully, but these errors were encountered:
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
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 withSIGTERM
potentially doing nothing and both taking an undefined length of time to take effect.The end result is
Output::Killed
is more of aOutput::MaybeKilled
.The text was updated successfully, but these errors were encountered: