Messages in this thread | | | Date | Wed, 13 Jun 2012 11:46:51 -0400 | Subject | Re: [PATCHv2 1/1] prctl: move pdeath_signal from task_struct to signal_struct | From | Albert Cahalan <> |
| |
On Tue, Jun 12, 2012 at 12:19 PM, Oleg Nesterov <oleg@redhat.com> wrote: > On 06/11, Filipe Brandenburger wrote:
> However. This code is very, very old. I simply do not know if we can > change the current behaviour or not. In particular, Albert Cahalan > didn't like this change when it was last discussed because it can > break his application. ... >> Documentation clearly states that PR_SET_PDEATHSIG and PR_GET_PDEATHSIG should >> act on processes, in particular case #1 is very counter intuitive because the >> child process should not care whether the parent is multi-threaded or not.
You are assuming that the child and parent are normal separate applications, developed by separate people, with one just being run by the other. That is actually the odd case AFAIK, because why then would there be reason to care about parent death? The more normal case IMHO is that the child and parent are deeply aware of each other. Most likely they are the same program.
In my case I have an in-process emulator, kind of like valgrind, that uses real threads for accuracy and performance. It makes extra threads for monitoring and control. These extra threads keep an eye on the app being examined; obviously none of this would work if the death signal were not per-thread.
Fix the documentation to match reality, then add a per-process one if there is any use for it. I don't think I've ever seen use for a per-process death signal, so perhaps it shouldn't be added even though it does make sense.
| |