Messages in this thread | | | Date | Tue, 5 Apr 2011 21:50:03 +0100 | From | Matt Fleming <> | Subject | Re: [RFC][PATCH 1/5] signals: Always place SIGCONT and SIGSTOP on 'shared_pending' |
| |
On Tue, 5 Apr 2011 22:19:58 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
> Hi Matt, > > I'll try to study this series, but not before Friday, sorry.
No problem!
> Only one thing, > > On 04/05, Matt Fleming wrote: > > > > Because SIGCONT and SIGSTOP affect an entire thread group, > > Yes, the effect is global, but > > > we can > > place them on the 'shared_pending' queue. > > I don't think we can. > > - pending = group ? &t->signal->shared_pending : &t->pending; > > + /* > > + * We always enqueue SIGSTOP or SIGCONT signals on the > > shared > > + * queue. This means that a SIGSTOP or SIGCONT signal > > _cannot_ > > + * be present on a thread's private pending queue. > > + * > > + * This makes prepare_signal() more optimal as we do not > > have > > + * to remove signals from each thread's pending queue and > > so > > + * can avoid iterating over all threads in the thread group > > + * (and therefore avoid the locking that would be > > necessary to > > + * do that safely). > > + */ > > + if (group || sig_kernel_stop(sig) || sig == SIGCONT) > > + pending = &t->signal->shared_pending; > > + else > > + pending = &t->pending; > > How so? Suppose the process has a handler for SIGCONT. Suppose this > process is not stopped. tkill(SIGCONT) should deliver the signal to > the right thread.
D'oh, yes. I think I got confused here. You're right, this won't work.
> SIGSTOP can't have the handler, still we shouldn't place it on the > shared list, debuggers won't be happy.
Urgh, debuggers actually peek at shared_pending and pending?
> Also. This code was changed very much, please do these changes on > top of > http://git.kernel.org/?p=linux/kernel/git/tj/misc.git;a=shortlog;h=refs/heads/ptrace
My patches are already based on that tree.
-- Matt Fleming, Intel Open Source Technology Center
| |