Clearly, the solution is to extend the `kill` syscall to accept the PID as a Gaussian integer, with both real and imaginary components. That way, we can preserve the current behavior of `kill(+123, sig)` and `kill(-123, sig)` as sending a signal to a single process or to a process group, respectively, and will then allow `kill(+123*i, sig)` as sending a signal to all processes that are either within a process group have a direct or indirect parent within that process group. I don't know what we'd use the negative imaginary numbers for, but I'm sure we could think of something.

If not for the uncatchable SIGKILL/SIGSTOP, I'd say that any process that calls `setsid` is responsible for ensuring signal propagation across the pgid. But since those are uncatchable, I tend to shrug and figure that I'll avoid setsid wherever possible.

There was a proposal at one point that would have had `unshare(NEW_CGROUP)` place the process into a child cgroup, rather than merely changing the name of the current cgroup. This would have meant that cgroups could actually be used for nested process management. Unfortunately, there's no guarantee that a process can ever make nested cgroups it wouldn't be sound for all supported resource constraints, so that proposal never went in. But that would have been nice to actually have nestable job management.

▲

Joker_vD 6 hours ago | parent [-]

> I'd say that any process that calls `setsid` is responsible for ensuring signal propagation across the pgid.

How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!

> But that would have been nice to actually have nestable job management.

Yes, it would be. Just imagine: a simple, straightforward way to group a bunch of processes (and their potential children, inescapably), signal them all at once, wait for them all at once, etc. Instead, we at best ended up with docker compose and k8s. And they kinda do solve that problem, no question about that but it's just so incredibly heavyweight...

▲

MereInterest 5 hours ago | parent [-]

> How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!

By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.

So, my phrasing was inaccurate to the point of being entirely incorrect. I should have said that any process that calls `setsid` is responsible for ensuring that signals are being propagated. (And saved! Definitely didn't make a mistake on the internet and then play it like I was right all along.)

	▲	Joker_vD 4 hours ago \| parent [-]
		> any process that calls `setsid` is responsible for ensuring that signals are being propagated. Well, again, the process that calls setsid(2) ceases to receive the signals from its previous process group, so there is nothing for it to propagate. The only way this propagation can work is with cooperation from the parent process of the setsid-calling process: it will need to manually pass the group-wide signals to its setsid-calling child — which it can't reliably do for two obvious reasons. > By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it. Wait. Are you implying a scheme where the process A, that wants to do setsid(2), forks itself, and it's this child process B that does setsid(2) and all future actual work, while process A merely lives in a "while(1) { sig = sigwait(); signal(pidB, sig); }" loop forever? This almost works but doesn't survive SIGSTOP/SIGCONT/etc. and, of course, you can't propagate SIGKILL. And SIGKILL-propagation is arguably one of the main attraction of the process groups — you send SIGKILL to the process group (or a container, for that matter), and all of it dies with no further work on your part.