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

ern0 wrote:

> > The kernel selects one thread which hasn't blocked the signal.
> 
> So if you want to catch signals ASAP, is it a good strategy to
> - leave one thread for signal catching, it may perform sleeps;
> - other threads should block all signals?

You should also set that thread to use real-time scheduling, and
mlock() any memory it requires.

The former ensures that, once the thread becomes runnable, it takes
precedence over other (non-real-time) threads. The latter ensures that
it can actually execute the signal-handling code in a reasonable time
(a thread which is normally idle is prone to having its memory paged
out).

Both of these are subject to resource limits. In particular, the
default for RLIMIT_RTPRIO is usually zero, which prevents selecting
real-time scheduling. The reason is that a real-time process takes
precedence over all non-real-time processes; if a real-time process
gets stuck in a loop, it will prevent non-real-time processes from
getting any CPU. RLIMIT_RTTIME can be used to mitigate this issue.

-- 
Glynn Clements <[email protected]>