Re: Do we really need curr_target in signal_struct ?

[Oleg Nesterov <oleg@redhat.com>]

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.