lkml.org 
[lkml]   [2014]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Do we really need curr_target in signal_struct ?
    On 02/04, Rakib Mullick wrote:
    >
    > On Mon, Feb 3, 2014 at 10:39 PM, Oleg Nesterov <oleg@redhat.com> wrote:
    >
    > > I can only read the current code. I do not know the original intent.
    > >
    > This is where things are confusing.

    Yes, I agree.

    Once again, I can understand what this code does, but I am not sure
    I understand why, and I am not sure this logic was actually "designed".
    The usual problem with the ancient code.

    > > I simply can't understand. Why? I do not think so.
    > >
    > Cause, want_signal logic checks these thread attributes to find whether it's
    > eligible or not.

    Ah, wants_signal()->signal_pending() doesn't mean "eligible".
    sigismember(&p->blocked) does mean.

    This signal_pending() checks allows to notify multiple threads, so that
    they can run the signal handlers in parallel. And otoh, if signal_pending()
    is true then we obviously do not need signal_wake_up().

    > And, therefore, I think I should not make any
    > changes in this code.

    No ;) not at all.

    We all do mistakes, and in this particular case I am not even 100% sure
    I was right.

    > > But I am not going to ack the behaviour change, simply because I have
    > > no idea how this can impact the existing applications. Perhaps nobody
    > > will notice this change, but we can't know this.
    > >
    > Yes, I'm not also sure about the behavior change and it's impact over
    > existing applications, so, I'm skipping it.

    Yes, this is the main reason why I disliked this change from the very
    beginning.

    Oleg.



    \
     
     \ /
      Last update: 2014-02-04 19:01    [W:3.661 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site