Date: Tue, 08 Jan 2013 15:02:24 +0800 From: David Xu <davidxu@freebsd.org> To: Richard Sharpe <rsharpe@richardsharpe.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Is it possible to block pending queued RealTime signals (AIO originating)? Message-ID: <50EBC480.8000306@freebsd.org> In-Reply-To: <1357626838.6752.27.camel@localhost.localdomain> References: <1357608470.6752.22.camel@localhost.localdomain> <50EB888A.2030802@freebsd.org> <1357626838.6752.27.camel@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013/01/08 14:33, Richard Sharpe wrote:
> On Tue, 2013-01-08 at 10:46 +0800, David Xu wrote:
>> On 2013/01/08 09:27, Richard Sharpe wrote:
>>> Hi folks,
>>>
>>> I am running into a problem with AIO in Samba 3.6.x under FreeBSD 8.0
>>> and I want to check if the assumptions made by the original coder are
>>> correct.
>>>
>>> Essentially, the code queues a number of AIO requests (up to 100) and
>>> specifies an RT signal to be sent upon completion with siginfo_t.
>>>
>>> These are placed into an array.
>>>
>>> The code assumes that when handling one of these signals, if it has
>>> already received N such siginfo_t structures, it can BLOCK further
>>> instances of the signal while these structures are drained by the main
>>> code in Samba.
>>>
>>> However, my debugging suggests that if a bunch of signals have already
>>> been queued, you cannot block those undelivered but already queued
>>> signals.
>>>
>>> I am certain that they are all being delivered to the main thread and
>>> that they keep coming despite the code trying to stop them at 64 (they
>>> get all the way up to the 100 that were queued.)
>>>
>>> Can someone confirm whether I have this correct or not?
>>>
>>
>> I am curious that how the code BLOCKs the signal in its signal handler ?
>> AFAIK, after signal handler returned, original signal mask is restored,
>> and re-enables the signal delivering, unless you change it in
>> ucontext.uc_sigmask.
>
> It does try to block the signals in the signal handler using the
> following code (in the signal handler):
>
> if (count+1 == TEVENT_SA_INFO_QUEUE_COUNT) {
> /* we've filled the info array - block this signal until
> these ones are delivered */
> sigset_t set;
> sigemptyset(&set);
> sigaddset(&set, signum);
> sigprocmask(SIG_BLOCK, &set, NULL);
>
> However, I also added pthread_sigmask with the same parameters to see if
> that made any difference and it seemed not to.
>
This code won't work, as I said, after the signal handler returned,
kernel will copy the signal mask contained in ucontext into kernel
space, and use it in feature signal delivering.
The code should be modified as following:
void handler(int signum, siginfo_t *info, ucontext_t *uap)
{
...
if (count + 1 == TEVENT_SA_INFO_QUEUE_COUNT) {
sigaddset(&uap->uc_sigmask, signum);
...
here, sigprocmask call should be removed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50EBC480.8000306>