Re: [PATCH] Only send pdeath_signal when getppid changes.

["Albert Cahalan" <acahalan@gmail.com>]

On 4/10/07, Roland McGrath <roland@redhat.com> wrote:
> > Does a parent death signal make most sense between separately written programs?
>
> I don't think it does.  It has always seemed an utterly cockamamy feature
> to me, and I've never understood what actually motivated it.

It's useful, but the other case is more important.

> > Does a parent death signal make most sense between processes that are part of
> > a larger program.
>
> That is the only way I can really see it being used.  The only actual
> example of use I know is what Albert Cahalan reported.  To my mind, the
> only semantics that matter for pdeath_signal are what previous uses
> expected in the past and still need for compatibility.  If we started with
> a fresh rationale from the ground up on what the feature is good for, I am
> rather skeptical it would pass muster to be added today.

Until inotify and dnotify work on /proc/12345/task, there really isn't
an alternative for some of us. Polling is unusable.

Ideally one could pick any container, session, process group,
mm, task group, or task for notification of state change.
State change means various things like destruction, addition
of something new, exec, etc. (stuff one can see in /proc)
With appropriate privs, having the debug-related stuff would be
good as well.