On 05 Oct 2015, at 3:41 PM, Jim Jagielski <[email protected]> wrote: > Of course, this could also result in the issue we currently > have w/ APR in which APR itself lags behind what httpd itself > needs and we end up add stuff to httpd anyway... > > Hmmmm...
This was my approach: I wanted the moon on a stick. What exactly constituted a moon on a stick? I wanted all of the following: - I wanted to make httpd asynchronous, and decisively allow httpd to join the list of servers that can support hundreds of thousands of concurrent requests across the board, not just as a special case for specific content (files). - I didn’t want to wait. This means I wanted whatever change I made to be backport-able to httpd v2.4. I don’t care to wait 5 years for httpd v2.6 to finally to appear as the default version in stable OS distros. - I wanted to work with what was already there. That meant making the existing ap_filter API and the existing buckets work with backwards compatible changes to httpd and no changes to apr/apr-util. - I wanted a mechanism that was not brittle. This is probably the hardest part of async programming, how do you prevent something spinning or hanging? When the new mechanism is used wrong the thread just becomes synchronous until the data is written and eventually works anyway, which is existing behaviour and not the end of the world. I am aware that some people have said that it couldn’t be done in httpd’s design. I figured let me test that hypothesis by trying anyway, the worst that could happen was that they were right but the server could at least be improved as best it could. I believe however that there is a good chance the moon on a stick has been achieved. Regards, Graham —
