Guys,

  I am writing an application where the parent (daemon) forks few
child processes.
My requirement is that when the parent process exits/killed/crashed,
all its child processes should also exit. Can someone suggest some way
of doing it.
Problematic scenario is the one where the parent crashed or killed
(SIGKILL) and desn't get any chance for cleanup.

thanks for any help..

junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
>   I am writing an application where the parent (daemon) forks few
> child processes.
> My requirement is that when the parent process exits/killed/crashed,
> all its child processes should also exit. Can someone suggest some way
> of doing it.
> Problematic scenario is the one where the parent crashed or killed
> (SIGKILL) and desn't get any chance for cleanup.

Since the child processes aren't informed about the death of
their parent you need to do a bit of extra work. One way to
do it would to regularly try to do

if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
	/* Parent process is probably dead */

But there's a slight chance that the PID of the dead parent
process has already been assigned to another, completely un-
related process in between. To avoid that you could create a
pipe in the parent and pass the write end to the child pro-
cesses. Now the child processes write (just a single byte)
to the pipe from time to time. If that results in a SIGPIPE
signal (or, if SIGPIPE is blocked, write() returns with an
error and errno is set to EPIPE) then the parent is dead.
Of course, you then also need e.g. a thread in the parent
that reads from the pipe from time to time (and throws away
what it read) to avoid it becoming full.

                            Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

jt@toerring.de (Jens Thoms Toerring) writes:
> junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
>>   I am writing an application where the parent (daemon) forks few
>> child processes.
>> My requirement is that when the parent process exits/killed/crashed,
>> all its child processes should also exit. Can someone suggest some way
>> of doing it.
>> Problematic scenario is the one where the parent crashed or killed
>> (SIGKILL) and desn't get any chance for cleanup.
>
> Since the child processes aren't informed about the death of
> their parent you need to do a bit of extra work. One way to
> do it would to regularly try to do
>
> if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
> 	/* Parent process is probably dead */
>
> But there's a slight chance that the PID of the dead parent
> process has already been assigned to another, completely un-
> related process in between. To avoid that you could create a
> pipe in the parent and pass the write end to the child pro-
> cesses. Now the child processes write (just a single byte)
> to the pipe from time to time. If that results in a SIGPIPE
> signal (or, if SIGPIPE is blocked, write() returns with an
> error and errno is set to EPIPE) then the parent is dead.
> Of course, you then also need e.g. a thread in the parent
> that reads from the pipe from time to time (and throws away
> what it read) to avoid it becoming full.

I suggest to do this the other way round, with the 'write end' in the
parent an the 'read end' in the children. The latter must be
configured as non-blocking. For as long as the parent still exists,
each read done in any of the children should return with -1, errno ==
EAGAIN. As soon as the parent is dead, the next read will return 0 to
indicate that there are no active writers.

Example program:
-------------------
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static void fork_child(int *fds)
{
    pid_t pid;
    int rc;

    pid = fork();
    switch (pid) {
    case -1:
	perror("fork");
	exit(1);

    case 0:
	break;

    default:
	return;
    }

    close(fds[1]);
    rc = fcntl(*fds, F_GETFL);
    fcntl(*fds, F_SETFL, rc | O_NONBLOCK);

    pid = getpid();
    while (rc = read(*fds, &rc, sizeof(rc)),
	   rc == -1 && errno == EAGAIN) {
	printf("\t%ld partying on\n", (long)pid);
	sleep(1);
    }

    printf("\t%ld: oh shit ...\n", (long)pid);
    _exit(0);
}

int main(void) 
{
    int fds[2], rc;

    rc = pipe(fds);
    if (rc == -1) {
	perror("pipe");
	exit(1);
    }

    fork_child(fds);
    fork_child(fds);
    
    close(*fds);
    sleep(10);
    puts("parent came home");

    return 0;
}

* jt@toerring.de (Jens Thoms Toerring)
| if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
| 	/* Parent process is probably dead */
| 
| But there's a slight chance that the PID of the dead parent process
| has already been assigned to another, completely un- related process
| in between.

On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
exited, which could be used as an indicator "parent has gone".  The
manpage says nothing about that scenario so I don't know how portable
that would be.

R'

Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
> > junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
> >>   I am writing an application where the parent (daemon) forks few
> >> child processes.
> >> My requirement is that when the parent process exits/killed/crashed,
> >> all its child processes should also exit. Can someone suggest some way
> >> of doing it.
> >> Problematic scenario is the one where the parent crashed or killed
> >> (SIGKILL) and desn't get any chance for cleanup.
> >
> > Since the child processes aren't informed about the death of
> > their parent you need to do a bit of extra work. One way to
> > do it would to regularly try to do
> >
> > if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
> >       /* Parent process is probably dead */
> >
> > But there's a slight chance that the PID of the dead parent
> > process has already been assigned to another, completely un-
> > related process in between. To avoid that you could create a
> > pipe in the parent and pass the write end to the child pro-
> > cesses. Now the child processes write (just a single byte)
> > to the pipe from time to time. If that results in a SIGPIPE
> > signal (or, if SIGPIPE is blocked, write() returns with an
> > error and errno is set to EPIPE) then the parent is dead.
> > Of course, you then also need e.g. a thread in the parent
> > that reads from the pipe from time to time (and throws away
> > what it read) to avoid it becoming full.

> I suggest to do this the other way round, with the 'write end' in the
> parent an the 'read end' in the children. The latter must be
> configured as non-blocking. For as long as the parent still exists,
> each read done in any of the children should return with -1, errno ==
> EAGAIN. As soon as the parent is dead, the next read will return 0 to
> indicate that there are no active writers.

Excellent! Hadn't thought about doing it the other way round. And
it avoids having the parent do anything at all.

                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

Ralf Fassel <ralfixx@gmx.de> writes:
> * jt@toerring.de (Jens Thoms Toerring)
> | if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
> | 	/* Parent process is probably dead */
> | 
> | But there's a slight chance that the PID of the dead parent process
> | has already been assigned to another, completely un- related process
> | in between.
>
> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
> exited, which could be used as an indicator "parent has gone".  The
> manpage says nothing about that scenario so I don't know how portable
> that would be.

Orphaned child processes are generally inherited by 'process #1'
(init).

On Dec 3, 5:56=A0am, Ralf Fassel <ralf...@gmx.de> wrote:

> On my Opensuse 11.1, getppid() returns 1 (=3D=3D init) when the parent ha=
s
> exited, which could be used as an indicator "parent has gone". =A0The
> manpage says nothing about that scenario so I don't know how portable
> that would be.

You can call 'getppid' on startup and check if it changes or is
equivalent to one. I guess this creates a narrow window in which your
parent could die, you could get reparented to something other than
init, and then you call getppid the first time.

On Dec 3, 8:43=A0pm, David Schwartz <dav...@webmaster.com> wrote:
> On Dec 3, 5:56=A0am, Ralf Fassel <ralf...@gmx.de> wrote:
>
> > On my Opensuse 11.1, getppid() returns 1 (=3D=3D init) when the parent =
has
> > exited, which could be used as an indicator "parent has gone". =A0The
> > manpage says nothing about that scenario so I don't know how portable
> > that would be.
>
> You can call 'getppid' on startup and check if it changes or is
> equivalent to one. I guess this creates a narrow window in which your
> parent could die, you could get reparented to something other than
> init, and then you call getppid the first time.

Guys, thanks a lot for your suggestions.
However, all the solutions suggested require regular polling, which I
want to avoid. Is there any way, where I can do this without polling?
Isn't this a very common requirement ?

On December 3, 2009 04:42, in comp.unix.programmer, junky_fellow@yahoo.co.in
(junky_fellow@yahoo.co.in) wrote:

> Guys,
> 
>   I am writing an application where the parent (daemon) forks few
> child processes.
> My requirement is that when the parent process exits/killed/crashed,
> all its child processes should also exit. Can someone suggest some way
> of doing it.

Make the parent process a "process group leader" before it forks off it's
children. Signals delivered to the "process group leader" are also
delivered to all of it's children.

A process that does not self-terminate (i.e. call exit() or equivalent)
terminates by signal. A "crash" condition causes the kernel to deliver one
of a select few signals to the process (SIGSEGV, for instance). If the
process is "killed" by another process, a signal is delivered to the
process.

The only real problem (in using a process group leader here) is that
self-termination usually does not involve signals, so there is no signal to
deliver to the child processes. However, since you have control over the
design and development of the parent process, you can incorporate a
signal-delivery-mechanism into your daemon's self-termination. Just before
calling exit() (or what ever you /do/ within the daemon to terminate it's
process), send a signal to all the children.

On the child process side, set up a signal handler that will terminate the
process cleanly when the appropriate signal is received. Include handling
for all the usual "kill" and "crash" signals, as well as for the signal
that you designate the parent to send (likely SIGHUP or SIGQUIT).

> Problematic scenario is the one where the parent crashed or killed
> (SIGKILL) and desn't get any chance for cleanup.

Signals delivered to the process group take care of this problem nicely.

> thanks for any help..

HTH
-- 
Lew Pitcher
Master Codewright & JOAT-in-training   | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
----------      Slackware - Because I know what I'm doing.         ------

junky_fellow@yahoo.co.in wrote:
> On Dec 3, 8:43 pm, David Schwartz <dav...@webmaster.com> wrote:
>> On Dec 3, 5:56 am, Ralf Fassel <ralf...@gmx.de> wrote:
>>
>>> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
>>> exited, which could be used as an indicator "parent has gone".  The
>>> manpage says nothing about that scenario so I don't know how portable
>>> that would be.
>> You can call 'getppid' on startup and check if it changes or is
>> equivalent to one. I guess this creates a narrow window in which your
>> parent could die, you could get reparented to something other than
>> init, and then you call getppid the first time.
> 
> Guys, thanks a lot for your suggestions.
> However, all the solutions suggested require regular polling, which I
> want to avoid. Is there any way, where I can do this without polling?

     Using Rainer Weikusat's suggestion of a pipe written ("not")
by the parent and read by the children, you could dedicate a
thread in each child process to sit in a (blocking) read on the
pipe and shut things down when the read returns end-of-input.

     If you don't like the idea of multi-threading, you could
write a single-threaded helper program that would be the child
of the parent, and would launch the "payload" program as the
parent's grandchild.  After fork, the helper would then block
reading the pipe, and kill the grandchild when the read completes.

> Isn't this a very common requirement ?

     Hard to say, but the available evidence suggests "No."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Lew Pitcher <lpitcher@teksavvy.com> writes:
> On December 3, 2009 04:42, in comp.unix.programmer, junky_fellow@yahoo.co.in
> (junky_fellow@yahoo.co.in) wrote:
>
>> Guys,
>> 
>>   I am writing an application where the parent (daemon) forks few
>> child processes.
>> My requirement is that when the parent process exits/killed/crashed,
>> all its child processes should also exit. Can someone suggest some way
>> of doing it.
>
> Make the parent process a "process group leader" before it forks off it's
> children. Signals delivered to the "process group leader" are also
> delivered to all of it's children.

This is wrong: Signals which are generated by the terminal driver in
response to user input (SIGINT, SIGQUIT and SIGTSTP) are sent to all processes
in the current foreground process group associated with a particular
terminal. This can be verified by running the program included below
in a shell with job-control support. Such a shell will put each 'new
job' into a process group of its own, so that SIGTSTP stops
'everything', which means the original process will be a process group
leader. After the sleep it does an invalid memory access and the
kernel terminates it with SIGSEGV. The the pausing children remain
running.

-------
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    int rc;

    if (fork() == 0) pause();
    if (fork() == 0) pause();

    fprintf(stderr, "%d\n", getpid() == getpgrp());
    sleep(1);

    *(int *)-1 = 3;
    return 0;
}

On 12/03/2009 10:47 AM, junky_fellow@yahoo.co.in wrote:
> On Dec 3, 8:43 pm, David Schwartz <dav...@webmaster.com> wrote:
>> On Dec 3, 5:56 am, Ralf Fassel <ralf...@gmx.de> wrote:
>>
>>> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
>>> exited, which could be used as an indicator "parent has gone".  The
>>> manpage says nothing about that scenario so I don't know how portable
>>> that would be.
>>
>> You can call 'getppid' on startup and check if it changes or is
>> equivalent to one. I guess this creates a narrow window in which your
>> parent could die, you could get reparented to something other than
>> init, and then you call getppid the first time.
> 
> Guys, thanks a lot for your suggestions.
> However, all the solutions suggested require regular polling, which I
> want to avoid. Is there any way, where I can do this without polling?
> Isn't this a very common requirement ?

We had a similar requirement to enable a "supervisor" monitoring process
to keep track of a bunch of unrelated app processes.  We ended up
writing some custom code in the kernel to allow a process to be sent an
arbitrary signal when any of a customizable set of events happened to an
arbitrary list of tasks.

If you did something like this the kids could request to be sent a
SIGTERM (or some other signal) when the parent dies.

Chris

Jens Thoms Toerring wrote:
> junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
>>   I am writing an application where the parent (daemon) forks few
>> child processes.
>> My requirement is that when the parent process exits/killed/crashed,
>> all its child processes should also exit. Can someone suggest some way
>> of doing it.
>> Problematic scenario is the one where the parent crashed or killed
>> (SIGKILL) and desn't get any chance for cleanup.
> 
> Since the child processes aren't informed about the death of
> their parent you need to do a bit of extra work. One way to
> do it would to regularly try to do
> 
> if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
> 	/* Parent process is probably dead */
> 
> But there's a slight chance that the PID of the dead parent
> process has already been assigned to another, completely un-
> related process in between. To avoid that you could create a
> pipe in the parent and pass the write end to the child pro-
> cesses. Now the child processes write (just a single byte)
> to the pipe from time to time. If that results in a SIGPIPE
> signal (or, if SIGPIPE is blocked, write() returns with an
> error and errno is set to EPIPE) then the parent is dead.
> Of course, you then also need e.g. a thread in the parent
> that reads from the pipe from time to time (and throws away
> what it read) to avoid it becoming full.

Why bother actually writing/reading?  Wouldn't it suffice to select() on the 
pipe within the child, to test whether the other side has been closed or not?

-- 
Kenneth Brody

On Dec 3, 8:47=A0am, "junky_fel...@yahoo.co.in"
<junky_fel...@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?

DS

On 12/03/2009 04:24 PM, David Schwartz wrote:
> On Dec 3, 8:47 am, "junky_fel...@yahoo.co.in"
> <junky_fel...@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.

Chris

On Dec 3, 2:57=A0pm, Chris Friesen <cbf...@mail.usask.ca> wrote:

> > 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. =A0Imagine 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.

Why couldn't they be seen by the parent's parent?

DS

On Dec 4, 3:20=A0am, Kenneth Brody <kenbr...@spamcop.net> wrote:
> Jens Thoms Toerring wrote:
> > junky_fel...@yahoo.co.in <junky_fel...@yahoo.co.in> wrote:
> >> =A0 I am writing an application where the parent (daemon) forks few
> >> child processes.
> >> My requirement is that when the parent process exits/killed/crashed,
> >> all its child processes should also exit. Can someone suggest some way
> >> of doing it.
> >> Problematic scenario is the one where the parent crashed or killed
> >> (SIGKILL) and desn't get any chance for cleanup.
>
> > Since the child processes aren't informed about the death of
> > their parent you need to do a bit of extra work. One way to
> > do it would to regularly try to do
>
> > if ( kill( getppid, 0 ) !=3D 0 && errno =3D=3D ESRCH )
> > =A0 =A0/* Parent process is probably dead */
>
> > But there's a slight chance that the PID of the dead parent
> > process has already been assigned to another, completely un-
> > related process in between. To avoid that you could create a
> > pipe in the parent and pass the write end to the child pro-
> > cesses. Now the child processes write (just a single byte)
> > to the pipe from time to time. If that results in a SIGPIPE
> > signal (or, if SIGPIPE is blocked, write() returns with an
> > error and errno is set to EPIPE) then the parent is dead.
> > Of course, you then also need e.g. a thread in the parent
> > that reads from the pipe from time to time (and throws away
> > what it read) to avoid it becoming full.
>
> Why bother actually writing/reading? =A0Wouldn't it suffice to select() o=
n the
> pipe within the child, to test whether the other side has been closed or =
not?
>
Thanks Brody and everyone else. I like this idea of using a select on
the pipe and socket. Hope this should solve the problem.

Kenneth Brody <kenbrody@spamcop.net> writes:
> Jens Thoms Toerring wrote:
>> junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
>>>   I am writing an application where the parent (daemon) forks few
>>> child processes.
>>> My requirement is that when the parent process exits/killed/crashed,
>>> all its child processes should also exit. Can someone suggest some way
>>> of doing it.
>>> Problematic scenario is the one where the parent crashed or killed
>>> (SIGKILL) and desn't get any chance for cleanup.
>>
>> Since the child processes aren't informed about the death of
>> their parent you need to do a bit of extra work. One way to
>> do it would to regularly try to do
>>
>> if ( kill( getppid, 0 ) != 0 && errno == ESRCH )
>> 	/* Parent process is probably dead */
>>
>> But there's a slight chance that the PID of the dead parent
>> process has already been assigned to another, completely un-
>> related process in between. To avoid that you could create a
>> pipe in the parent and pass the write end to the child pro-
>> cesses. Now the child processes write (just a single byte)
>> to the pipe from time to time. If that results in a SIGPIPE
>> signal (or, if SIGPIPE is blocked, write() returns with an
>> error and errno is set to EPIPE) then the parent is dead.
>> Of course, you then also need e.g. a thread in the parent
>> that reads from the pipe from time to time (and throws away
>> what it read) to avoid it becoming full.
>
> Why bother actually writing/reading?  Wouldn't it suffice to select()
> on the pipe within the child, to test whether the other side has been
> closed or not?

As long as there aren't multiple descriptors involved (as in
simplified examples), there is not reason to use I/O-multiplexing
routines.

Ralf Fassel wrote:

> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
> exited, which could be used as an indicator "parent has gone".  The
> manpage says nothing about that scenario so I don't know how portable
> that would be.

POSIX says that when a process terminates:

    The parent process ID of all of the existing child processes and
    zombie processes of the calling process shall be set to the
    process ID of an implementation-defined system process. That is,
    these processes shall be inherited by a special system process.

(This is from the description of _exit() which is why it says "calling
process", but the same applies to all forms of termination.)

Traditionally the "special system process" is init, and has PID 1, but
a different PID could be used on non-traditional systems.  This makes
parent death harder to detect because, as someone pointed out elsewhere
in the thread, if you repeatedly call getppid() checking whether the
return value has changed there is a chance that the parent has already
died before your first call to getppid().  This problem can be avoided
by having the parent pass its PID to the child.

-- 
Geoff Clare <netnews@gclare.org.uk>

On 12/03/2009 05:16 PM, David Schwartz wrote:
> On Dec 3, 2:57 pm, Chris Friesen <cbf...@mail.usask.ca> wrote:
> 
>>> 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.
> 
> 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.

Chris

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
> Ralf Fassel wrote:
>> On my Opensuse 11.1, getppid() returns 1 (== init) when the parent has
>> exited, which could be used as an indicator "parent has gone".  The
>> manpage says nothing about that scenario so I don't know how portable
>> that would be.
>
> POSIX says that when a process terminates:
>
>     The parent process ID of all of the existing child processes and
>     zombie processes of the calling process shall be set to the
>     process ID of an implementation-defined system process. That is,
>     these processes shall be inherited by a special system process.
>
> (This is from the description of _exit() which is why it says "calling
> process", but the same applies to all forms of termination.)
>
> Traditionally the "special system process" is init, and has PID 1, but
> a different PID could be used on non-traditional systems.  This makes
> parent death harder to detect because, as someone pointed out elsewhere
> in the thread, if you repeatedly call getppid() checking whether the
> return value has changed there is a chance that the parent has already
> died before your first call to getppid().  This problem can be avoided
> by having the parent pass its PID to the child.

Since this is already in the realm of theory: The 'special system
process' could have the same process ID as the original parent
process (at least insofar the quoted text is concerned).

On Dec 4, 10:08=A0am, Chris Friesen <cbf...@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. =A0In 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

On 12/04/2009 01:32 PM, David Schwartz wrote:
> On Dec 4, 10:08 am, Chris Friesen <cbf...@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

Chris Friesen wrote:
> On 12/03/2009 04:24 PM, David Schwartz wrote:
>> On Dec 3, 8:47 am, "junky_fel...@yahoo.co.in"
>> <junky_fel...@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.

>
>>>
>>> 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.
>
.... which is the very raison d'�tre of SIGPIPE.