Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Oct 2009 14:33:03 +0800
From:      David Xu <davidxu@freebsd.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, Justin Teller <justin.teller@gmail.com>
Subject:   Re: Signals and an exiting thread
Message-ID:  <4AD17C1F.8020709@freebsd.org>
In-Reply-To: <20091010143643.GA2259@deviant.kiev.zoral.com.ua>
References:  <c47019cc0909301102y189a0b8aq47d23efae549f4ab@mail.gmail.com>	<20091001120730.GR3130@deviant.kiev.zoral.com.ua>	<20091002201213.GA16633@stack.nl>	<20091005192144.GA2259@deviant.kiev.zoral.com.ua>	<4AD01ABC.50901@freebsd.org> <20091010143643.GA2259@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AD17C1F.8020709>