Re: [PATCH] Only send pdeath_signal when getppid changes.
On 4/10/07, Roland McGrath <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
> 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. > 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. Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
Oleg Nesterov <[EMAIL PROTECTED]> writes: > On 04/10, Eric W. Biederman wrote: >> >> So this patch fixes the pdeath_signal behaviour only sending a signal >> when the results of getppid would change. > > Don't get me wrong, I personally like this patch very much. However, Good point. I guess we have a simple question. Does a parent death signal make most sense between separately written programs? If so this patch is a bug fix. Does a parent death signal make most sense between processes that are part of a larger program. If so there is little point to this patch. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 04/10, Eric W. Biederman wrote: > > So this patch fixes the pdeath_signal behaviour only sending a signal > when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, A long ago, Albert Cahalan (cc-ed) wrote: > > I rely on thread-to-thread pdeath notification for my emulator. > I also need notification on loss of a thread-group or mm, so I do > my best to emulate those based on thread-to-thread notification. > > ... > > The way I use it pdeath_signal: > > The parent is one of many tasks within a task group. > The child is not within that thread group, but shares VM. > (the child is single threaded, existing only to get the signal) > For each task in the thread group, there is a child task > waiting for parent death notification. (there are two other > tasks sharing VM but not in the task group: one to do > async memory searching, and one to communicate with > a user interface for debugging -- like an interactive valgrind) Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 04/10, Eric W. Biederman wrote: So this patch fixes the pdeath_signal behaviour only sending a signal when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, A long ago, Albert Cahalan (cc-ed) wrote: I rely on thread-to-thread pdeath notification for my emulator. I also need notification on loss of a thread-group or mm, so I do my best to emulate those based on thread-to-thread notification. ... The way I use it pdeath_signal: The parent is one of many tasks within a task group. The child is not within that thread group, but shares VM. (the child is single threaded, existing only to get the signal) For each task in the thread group, there is a child task waiting for parent death notification. (there are two other tasks sharing VM but not in the task group: one to do async memory searching, and one to communicate with a user interface for debugging -- like an interactive valgrind) Oleg. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
Oleg Nesterov [EMAIL PROTECTED] writes: On 04/10, Eric W. Biederman wrote: So this patch fixes the pdeath_signal behaviour only sending a signal when the results of getppid would change. Don't get me wrong, I personally like this patch very much. However, Good point. I guess we have a simple question. Does a parent death signal make most sense between separately written programs? If so this patch is a bug fix. Does a parent death signal make most sense between processes that are part of a larger program. If so there is little point to this patch. Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
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. 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. Thanks, Roland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 4/10/07, Roland McGrath [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
