On Sat, 2010-07-10 at 17:59 -0500, Dallas Clement wrote: > Hi All, > > 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. [...]
A signal sent to a multithreaded process will be delivered to one of its threads, and unless you specifically mask signals then it could be delivered to any of them. You can either use signal masking to ensure that only the dispatcher thread receives these signals, or have the signal handler wake the dispatcher by writing to a control pipe included in the select(). Anyway, you are asking on the wrong list. This is about development of the Debian system, not development of programs using Debian. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
