Kilau, Scott wrote:
>
> signal_pending() never does, no matter how many signals I send it.
> (Even sending it multiple kill -9's)
>
> ...
>
> However, I see the signals climb, when I print out the values of
> current->signal->shared_pending.list.next and
> current->signal->shared_pending.list.prev
>
> Its like those values and the signal_pending macro aren't in "synch"
> Anymore, once the process has gone into the PF_EXITING state.
> (It works fine when the process is not in that state)
Yes, __group_complete_signal() is called after the signal has been added to
the ->shared_pending. But it does not signal_wake_up()s process, because of
this check in wants_signal():
if (p->flags & PF_EXITING)
return 0;
The intent was to find another thread in the thread group which can accept
this signal. May be we need special check in __group_complete_signal() under
"else if (thread_group_empty(p))".
You still can kill this process via tkill, though.
Oleg.
On Sad, 2005-10-15 at 20:14 +0400, Oleg Nesterov wrote:
> The intent was to find another thread in the thread group which can accept
> this signal. May be we need special check in __group_complete_signal() under
> "else if (thread_group_empty(p))".
The serial layer effectively relies on the old behaviour so yes.