lkml.org 
[lkml]   [2012]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCHv2 1/1] prctl: move pdeath_signal from task_struct to signal_struct
    From
    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.


    \
     
     \ /
      Last update: 2012-06-13 18:21    [W:0.039 / U:328.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site