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
<glynn@xxxxxxxxxxxxxxxxxx> 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 <glynn@xxxxxxxxxxxxxxxxxx>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
