Yes, there is task group concept and support by kill API directly: https://pubs.opengroup.org/onlinepubs/009604499/functions/kill.html
If *pid* is negative, but not -1, *sig* shall be sent to all processes (excluding an unspecified set of system processes) whose process group ID is equal to the absolute value of *pid*, and for which the process has permission to send a signal. https://en.wikipedia.org/wiki/Process_group But nuttx doesn't support task sesion/group yet, so the simple solution is extend kill command instead. On Mon, Jan 16, 2023 at 12:31 PM Gregory Nutt <spudan...@gmail.com> wrote: > That wouldn’t be consistent with how Linux works, would it? I'm not an > expert on this topic and I am sure that other people on this list know more > about this than me. My understanding is that Linux has "session leaders" > which correspond to login sessions. For each terminal opened by the > session leader, a "controlling terminal" is created that has at least two > process groups: a foreground and a background process group which may > consist of several processes. Multiple process groups can be managed with > interfaces like setpgid(). Sessions can be managed with interfaces like > setsid(). > > > The process groups get killed when the terminal is closed (unless it is > daimonized). The kill command also supports syntax to kill process > groups. Killing all processes or killing of all child processes is not > supported AFAIK. > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows > > > > *From: *Xiang Xiao <xiaoxiang781...@gmail.com> > *Sent: *Sunday, January 15, 2023 9:54 PM > *To: *dev@nuttx.apache.org > *Subject: *Re: How to automatically kill all children threads when the main > thread die > > > > If CONFIG_SIG_DEFAULT, the kernel will terminate all child pthreads, but > > not child tasks. > > We can extend kill to support -P flag like pkill: > > https://linux.die.net/man/1/pkill > > -P ppid,... > > Only match processes whose parent process ID is listed. > > > > On Mon, Jan 16, 2023 at 10:14 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > he > > > > > > > Ooops. No, you a re asking about tasks, not threads. That is easier. > > > > The answer is no: One task exiting has not effect at all any other > > > tasks. > > > > > > > > > > The question is confusing because it asks about killing other threads > (aka > > > pthreads) when the main (task) exits. But the example shows only tasks > > > (main threads). > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Tasks+vs.+Threads+FAQ > > > > > > > > > > > > > >> On Sun, Jan 15, 2023 at 5:25 PM Alan C. Assis <acas...@gmail.com> > > > wrote: > > > >> > > > >>> Dear NuttXers, > > > >>> > > > >>> I want to know if there are some hidden configuration that forces all > > > >>> children to die when the father task die. > > > >>> > > > >>> Currently only teh main task dies: > > > >>> > > > >>> nsh> family & > > > >>> > > > >>> nsh> ps > > > >>> PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK > STACK > > > >>> COMMAND > > > >>> ... > > > >>> 27 27 100 RR Task --- Waiting Signal 00000000 > 004032 > > > >>> family > > > >>> 28 28 100 RR Task --- Waiting Semaphore 00000000 > > > >>> 004032 child1_daemon > > > >>> 29 29 100 RR Task --- Waiting Signal 00000000 > > > >>> 004032 child2_daemon > > > >>> 30 30 100 RR Task --- Waiting Signal 00000000 > > > >>> 001984 child3_daemon > > > >>> > > > >>> nsh> kill 27 > > > >>> nsh> ps > > > >>> PID GROUP PRI POLICY TYPE NPX STATE EVENT SIGMASK > STACK > > > >>> COMMAND > > > >>> ... > > > >>> 28 28 100 RR Task --- Waiting Signal 00000000 > > > >>> 004032 child1_daemon > > > >>> 29 29 100 RR Task --- Waiting Signal 00000000 > > > >>> 004032 child2_daemon > > > >>> 30 30 100 RR Task --- Waiting Signal 00000000 > > > >>> 001984 child3_daemon > > > >>> > > > >>> I could setup a signal handling to handle the kill signal in the main > > > >>> task and use it to change the value of some conditional variable that > > > >>> maintain the threads loop of each child running, this is is an > option, > > > >>> but maybe there are better option. > > > >>> > > > >>> Please let me know how you are solving this issue. > > > >>> > > > >>> BR, > > > >>> > > > >>> Alan > > > >>> > > > >> > > > >
