Re: Slow signal delivery to server process with heavy I/O

It's the delivery that's slow.  If other threads are busy making other
I/O system calls such as 'send', 'recv', 'select' etc, the kernel
seems loathe to interrupt them for the sake of delivering a signal.
Eventually, the signal handling thread gets a turn, but I guess I was
under the false impression that a signal would be like a true
interrupt and preempt any executing user code.

On Sun, Jul 11, 2010 at 8:18 AM, Glynn Clements
<[email protected]> wrote:
>
> Dallas Clement wrote:
>
>> I've noticed that asynchronous signals such as SIGINT, SIGTERM etc are
>> delivered to my process long after the signal is sent if the receiving
>> process is handling lots of I/O.  My process is a multi-threaded web
>> server.  It's got one thread waiting on 'select' to accept incoming
>> connections and a thread pool which reads the data with 'recv'.
>>
>> When I batter the web server with incoming traffic and I try to
>> shutdown the server by sending a SIGINT or SIGTERM, I have observed
>> that the web server finishes handling the incoming traffic before the
>> kernel dispatches the signal to the process.  It appears that the
>> 'select' and 'recv' calls are getting highest priority with regard to
>> scheduling.
>>
>> I realize this test may appear unnatural and is perhaps unrealistic,
>> but I would like to be able to shutdown my server gracefully within a
>> reasonable amount of time, no matter what kind of load it is handling.
>>  Don't want to have to wait several minutes for my signals to get
>> handled under heavy load.  Could someone please explain why signal
>> delivery is slow under these conditions?
>
> Is it delivery that's slow, or handling? A thread which is executing a
> signal handler doesn't get any additional priority. And if there is
> intensive disk I/O, paging in the block containing the signal handler
> won't get prioritised over other disk I/O.
>
> Also: historically, the kernel hasn't been particularly intelligent
> about choosing which thread received the signal (at one time, it
> didn't even take into account whether the thread had blocked the
> signal). It wouldn't surprise me if it's willing to deliver the signal
> to a thread which is in uninterruptible sleep ("D" state).
>
> --
> Glynn Clements <[email protected]>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html