how to kill all child when parent exits
in [Unix Programming]
|
From: David Schwartz on 4 Dec 2009 14:32 On Dec 4, 10:08 am, Chris Friesen <cbf...(a)mail.usask.ca> wrote: > > Why couldn't they be seen by the parent's parent? > The tasks would be seen, but the results of the work they do may not be > understood by the parent's parent. In that case we may as well arrange > for the kids to die as well since they're effectively doing work for no > purpose. So we magically assume the parent knows exactly what the child is going to do, but we also assume the parent's parent is completely ignorant? This sounds like we have a solution, and then we go design a problem around it. DS
From: Chris Friesen on 4 Dec 2009 16:17 On 12/04/2009 01:32 PM, David Schwartz wrote: > On Dec 4, 10:08 am, Chris Friesen <cbf...(a)mail.usask.ca> wrote: > >>> Why couldn't they be seen by the parent's parent? > >> The tasks would be seen, but the results of the work they do may not be >> understood by the parent's parent. In that case we may as well arrange >> for the kids to die as well since they're effectively doing work for no >> purpose. > > So we magically assume the parent knows exactly what the child is > going to do, but we also assume the parent's parent is completely > ignorant? This sounds like we have a solution, and then we go design a > problem around it. If I arrange for something to be started by init, and that process forks off a bunch of helpers, then does something wrong and dies....why would init be expected to know what the helpers are doing? Certainly you can construct ways of dealing with this issue, but there are absolutely scenarios where being able to be asynchronously notified when arbitrary processes exit (or stop, or continue, or trap) could be useful. Chris
From: Golden California Girls on 4 Dec 2009 20:24
Chris Friesen wrote: > On 12/03/2009 04:24 PM, David Schwartz wrote: >> On Dec 3, 8:47 am, "junky_fel...(a)yahoo.co.in" >> <junky_fel...(a)yahoo.co.in> wrote: >> >>> Isn't this a very common requirement ? >> No. In fact, it seems fundamentally broken to me. Why do you think you >> need/want to do this? > > I can think of some scenarios. Imagine a case where the parent forks > off a bunch of child processes to do some work, expecting to get the > results back via return codes, pipes, or something else. > > If the parent dies for whatever reason, it would make sense to kill the > child processes because any work they do won't be seen by anyone anymore. In that exceptional case I suppose so. In the more general case the file system can pass all work done to everyone. The parent could even be restarted and get the work. If the work time is going to be significant it is smarter to write the whole thing to expect a crash in the middle and pick up where it left off. |