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

Dallas Clement wrote:

> It's the delivery that's slow.

Out of interest, how did you manage to distinguish between delivery
and handling?

> 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.

The kernel selects one thread which hasn't blocked the signal. If the
thread is performing a blocking system call (interruptable sleep), it
will be interrupted (changed to runnable, allowing it to receive a
time slice). The next time that the thread is scheduled, the signal
handler will be invoked.

The kernel won't necessarily deliver the signal to the next thread to
be scheduled, and won't necessarily schedule the thread prematurely. 
However, this shouldn't cause a noticeable delay unless the system has
a vast number of runnable threads/processes and a low HZ value (i.e. 
if the time taken to schedule every runnable thread once is long).

If you require urgent delivery of a signal, you need to select
real-time scheduling (sched_setscheduler() with SCHED_FIFO or
SCHED_RR). This allows the thread to "jump the queue", pre-empting
lower-priority threads. In practice, you also need to mlock() any
memory required by the handler, to prevent delays caused by paging.

-- 
Glynn Clements <[email protected]>