Messages in this thread | | | Date | Tue, 4 Feb 2014 18:34:06 +0100 | From | Oleg Nesterov <> | Subject | Re: 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.
| |