Send a signal to the process group led by the given process id, falling back
to the process itself.
This is for children spawned with detached: true, which makes each child
the leader of its own process group: signalling the group also stops any
grandchildren the child spawned.
It is safe for non-detached children too. A process group's id is its
leader's pid, so -pid names a group only when this child leads one; for a
non-detached child no such group exists and the OS reports ESRCH. (It cannot
signal this process's group by accident: that group is named by its own
leader's pid, which is alive and so can't have been reassigned to a child.)
Since a silent no-op here would leak the child we were asked to kill, we then
signal the pid directly -- and if the child is simply already gone, that's
another harmless ESRCH.
Windows has no POSIX process groups, so there this behaves like kill.
Parameters
pid: number|undefined
the process group leader's id (a positive pid). Required.
force: boolean = false
if true, SIGKILL rather than SIGTERM. Defaults to false.
Send a signal to the process group led by the given process id, falling back to the process itself.
This is for children spawned with
detached: true, which makes each child the leader of its own process group: signalling the group also stops any grandchildren the child spawned.It is safe for non-detached children too. A process group's id is its leader's pid, so
-pidnames a group only when this child leads one; for a non-detached child no such group exists and the OS reports ESRCH. (It cannot signal this process's group by accident: that group is named by its own leader's pid, which is alive and so can't have been reassigned to a child.) Since a silent no-op here would leak the child we were asked to kill, we then signal the pid directly -- and if the child is simply already gone, that's another harmless ESRCH.Windows has no POSIX process groups, so there this behaves like kill.