unbit/uwsgi — pull request #33 by prymitive (2012-10-25 13:30:02+00:00)
Title: More accurate harakiri counting

I've noticed big harakiri spikes in my carbon stats and after checking logs it turns out it's just one worker pid getting harakiri many SIGKILLs:

```
Oct 25 08:33:55 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:33:55 localhost app: HARAKIRI: -- wchan> wait_answer_interruptible
Oct 25 08:33:57 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:33:57 localhost app: HARAKIRI: -- wchan> request_wait_answer
Oct 25 08:33:59 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:33:59 localhost app: HARAKIRI: -- wchan> request_wait_answer
Oct 25 08:34:01 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:34:01 localhost app: HARAKIRI: -- wchan> request_wait_answer
Oct 25 08:34:03 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:34:03 localhost app: HARAKIRI: -- wchan> request_wait_answer
Oct 25 08:34:05 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:34:05 localhost app: HARAKIRI: -- wchan> request_wait_answer
Oct 25 08:34:07 localhost app: *** HARAKIRI ON WORKER 4 (pid: 10469) ***
Oct 25 08:34:07 localhost app: HARAKIRI: -- wchan> request_wait_answer
```

Problem is that if process hangs and harakiri tries to kill it, it doesn't need to die instantly, AFAIK it can be running for a while if it waits for I/O. So I've added ```worker[nr].pending_harakiri``` to mark number of SIGKILLs recived by given worker, ```worker[nr].harakiri_count``` is only incremented if ```pending_harakiri == 0```