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