sylt

@benoitc Thanks for having a look! It's great to know some history as well behind the code -- git blame didn't help me much there unfortunately. I'll answer your findings...

@tilgovi Alright, thanks for the correction, that's a relief to hear it works in such a way! :) Well, then I guess commit 2 in this PR shouldn't be needed...

@benoitc I have made an alternative approach [here](https://github.com/benoitc/gunicorn/compare/master...sylt:gunicorn:dont_remove_workers_in_signal_handler) with the following highlights: * SIGCHLD is handled separately, just as before. * The signal queue with rate limiting (< 5 items)...

Without really checking what PRs were opened already, I posted a PR yesterday (#3148) with an attempt at solving various signal handling issues in gunicorn I had the misfortune to...

I've debugged the issue, and I think the smallest diff for fixing it (while maintaining the functionality of #2917) is: ```diff diff --git a/gunicorn/workers/gthread.py b/gunicorn/workers/gthread.py index c9c42345..9c1a92ad 100644 --- a/gunicorn/workers/gthread.py...

I think this is might be solved by #3148, at least with the change-set that I primarily propose. At I didn't get the assert when trying it out with that.

@KristjanESPERANTO: Yes, of course, thank you :) I have corrected the description! And just to show-case the difference between using `execSync` and `exec`, here's an example program when starting a...

Seems to be tied to the UvicornWorker worker class, as e.g. sync seems to work fine. The following patch would fix it for uvicorn workers though: ```python diff --git a/gunicorn/workers/base.py...

I wasn't aware of this pr until now, but FYI, I've posted #3148 which also aims to handle SIGCHLD on the main thread, although in a slightly different way.

@benoitc OK, thanks for giving it a look! Hmm, instead of adding an Arbiter:sleep() method, I added an Arbiter:wakeup() method, so that "fast" wakeups of the arbiter can be requested...