On Sat, Jul 15, 2017 at 6:50 AM, Gabor Szabo <szab...@gmail.com> wrote:
> If I run this in one terminal and run "ps axuw" in another terminal I > see 2 processes running. > If I press Ctrl-C in the terminal where I launched the program, both > processes are closed. > > OTOH If I run "kill PID" with the process ID of the parent process > then only that process is killed. The child process is still waiting > for the prompt. > > It does not make any difference if I use kill PID, or kill -2 PID or > kill -3 PID. > > I'd understand that "kill PID" leaves the child process but then why > does Ctrl-C kill both? And then how comes "kill -2 PID", which as I > understand must be the same SIGINT as the Ctrl-C, only kills the > parent? > Ctrl-C sends SIGINT to all processes in the terminal's foreground process group. There is no concept of "current process" on a terminal; Unixlike systems are multitasking, and all processes in the process group have access to the terminal, and there is no way for the OS to consider one of them to be "the current process". (Indeed, it is possible, if unfortunate, for multiple processes to be reading from the terminal at the same time.) That only one such process can be considered by users to be "current" is merely convention, and one that is easy to violate. (Shells make it more difficult by forcing command pipelines into separate process groups, and controlling them by sending signals to the process group; if running in the foreground, it will be assigned as the terminal's current process group. If a process in such process group *not* in the terminal's foreground process group tries to read from the terminal, it gets SIGTTIN; if it tries to write, it gets SIGTTOU. If these are not specifically handled by the process, they turn into SIGSTOP. This allows shells to maintain the illusion that there is a "current process", provided that only the first process in a pipeline reads from the terminal.) "ps -ej" shows processes by their process id, process group id, and session id (a session being a collection of process groups; all process groups created by a given interactive shell are in the same session). Typically "kill" (both shell and API) with a negative "process id" treats that as a negated process group id instead and sends the signal to the entire process group. I don't think Rakudo currently exposes any access to the process group or session, because this is POSIX-specific (Windows has its own mechanisms, which can be just as surprising). Proc::Async always runs things in its current process group. In short: Rakudo is not doing anything special here, you are seeing normal POSIX behavior. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
