With FreeBSD 8.0 it seems like you can't block pending but undelivered signals

[Richard Sharpe]

On Tue, Jan 8, 2013 at 10:59 AM, Jeremy Allison <jra at samba.org> wrote:
> On Tue, Jan 08, 2013 at 10:02:24AM -0800, Richard Sharpe wrote:
>> On Tue, Jan 8, 2013 at 9:06 AM, Jeremy Allison <jra at samba.org> wrote:
>> > On Tue, Jan 08, 2013 at 08:51:10AM -0800, Richard Sharpe wrote:
>> >> Hi folks,
>> >>
>> >> I have looked more at the AIO and signal issues I am seeing with
>> >> FreeBSD. This is FreeBSD 8.0.
>> >>
>> >> After instrumenting the code in lib/tevent/tevent_signal.c, I know:
>> >>
>> >> 1. Only one thread, the main thread is receiving signals.
>> >>
>> >> 2. When we hit 64 siginfo_t structures in our array, we try to stop
>> >> the delivery of further signals (signum=68, one of the RT signals
>> >> under FreeBSD.)
>> >>
>> >> 3. They keep coming, overwriting earlier ones and causing replays of
>> >> already handled events.
>> >>
>> >> I will be reading the FreeBSD source code some more today to try to
>> >> figure out what is going on.
>> >>
>> >> The work-around is to change the size of the array for siginfo_t
>> >> structures to 128 from 64 so it is larger than the number of pending
>> >> AIO requests (100).
>> >
>> > Are you saying that this code:
>> >
>> >                 sigset_t set;
>> >                 sigemptyset(&set);
>> >                 sigaddset(&set, signum);
>> >                 sigprocmask(SIG_BLOCK, &set, NULL);
>> >
>> > fails to block RT signals on FreeBSD ? That would seem
>> > like a horrible *BSD bug (IMHO).
>>
>> Well, this page:
>> http://www.gnu.org/software/libc/manual/html_node/Blocking-for-Handler.html#Blocking-for-Handler
>>
>> says:
>>
>> "You cannot remove signals from the process's current mask using this
>> mechanism. However, you can make calls to sigprocmask within your
>> handler to block or unblock signals as you wish.
>>
>> In any case, when the handler returns, the system restores the mask
>> that was in place before the handler was entered. If any signals that
>> become unblocked by this restoration are pending, the process will
>> receive those signals immediately, before returning to the code that
>> was interrupted."
>>
>> Now, I am not sure what sort of authority GNU is in this regard,
>> however, it seems that you cannot block the signal the invoked you, if
>> I am reading this statement correctly.
>>
>> And this seems to be what is happening.
>
> bugger, yes I think you're right. We've had this problem
> before (why do we never learn :-).
>
> Ok, I'll think on this some more...

OK, it seems that it is not so bad. Based on a response I got from the
FreeBSD Hackers mailing list, and some digging, I think the answer is:

            sigaddset(&((ucontext_t *)uctx)->uc_sigmask, sig);

I will try this soon and get back to you.

>From here: http://stackoverflow.com/questions/5531006/returning-from-a-signal-handler-and-leaving-signal-masked

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)