Description:
------------
The FPM pm.ondemand process manager has a subtle bug in the way it uses edge-triggered polling (with epoll() or kqueue()) that causes it not to notice when multiple requests arrive at the same time, and thus not to fork the appropriate number of children to handle them.  The bug was introduced during pm.ondemand's initial development, when the author switched from level-triggered select/poll to edge-triggered epoll/kqueue in order to a different bug that resulted in the fpm parent process entering a cpu spin loop for brief periods when new requests arrived.

The details of the bug are too subtle to fully describe here.  However, the PR I am about to submit for this bug report contains a new DESIGN.md file that includes a thorough explanation.



Test script:
---------------
I do not know how to create a self-contained test case for this.  However, using a custom web-testing tool I wrote called Goofy (https://github.com/bjaspan/goofy), it is easy to reproduce.  The README file in that repo shows using Goofy to demonstrate the exact bug in FPM that I am reporting here.

Expected result:
----------------
When N requests arrive nearly simultaneously, and FPM is allowed to fork N more processes, it should fork N more processes.

Actual result:
--------------
When N requests arrive nearly simultaneously, and FPM is allowed to fork N more processes, it almost always forks fewer than N processes, usually a lot fewer.  The exact number depends on race conditions with the fpm parent, children, epoll in the kernel, and who knows what else.