Re: Signals and an exiting thread

Kostik Belousov wrote:
> On Sat, Oct 10, 2009 at 01:25:16PM +0800, David Xu wrote:
>   
>> Kostik Belousov wrote:
>>
>>     
>>> I agree that postponing assignment of the thread for signal delivery
>>> till the actual delivery occurs is the proper fix. I tried to cheat
>>> in my previous patch. Below is an experimental change that did very
>>> minimal testing.
>>> <snip>
>>>       
>> Even if the signal is put into process's signal queue, it is still
>> possible that signal notification is lost because selected thread
>> exits before seeing it, if other threads are sleeping, they are
>> not notified, this leaves signal in process queue long time before
>> it can be delivered to userland.
>>
>>     
>
> Agreed. Actually, there is one more race. Namely, when thread enters
> kernel for executing sigprocmask syscall, but still did not acquired
> process mutex, some signal may be scheduled for the thread which will
> block it later while still in kernel, so wakeup is lost again. I did
> fixed that in later version of the patch, by waking up possible target
> threads that have newly blocked signals unblocked.
>
> Resulting code seems to be relevant for exiting thread as well, where
> we also shall set sigmask to indicate that thread is not willing (cannot)
> handle any further signals.
>
> Updated patch below.
>   

The patch looks fine to me.