httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <>
Subject Re: Should ap_bread et. al. be modified to work with async i/o APIs?
Date Wed, 12 Apr 2000 16:37:03 GMT
On Thu, 13 Apr 2000 01:54:42 +1000 (EST), Brian Havard wrote:

>On Wed, 12 Apr 2000 11:31:16 -0400, Bill Stoddard wrote:
>>> On Wed, 12 Apr 2000 11:00:02 -0400, Bill Stoddard wrote:
>>> >The anonymous pipes Windows uses to talk to CGI scripts are always
>>> >(and cannot be set non-blocking). I'm trying to fix this in Apache 2.0
>>> >have gotten bogged down in uglyness.
>>> The situation is the same on OS/2, that is unnamed pipes cannot be
>>> non-blocking, just like files can't.
>>> How about another tactic for handling stalled CGIs? We could spawn a
>>> watchdog thread that would kill the CGI if it stopped responding for too
>>> long. The CGI's death would close the pipes causing them to unblock with
>>> EOF.
>>That solves one problem. The problem I see reported most often is related to
>>Apache not sending data back to the browser until after the CGI terminates.
>>Take a look at ap_send_fb_length(). On Unix, if we make a non-blocking read
>>that returns 0 bytes, we flush the outbound network buffer before moving to
>>the blocking read. This lets CGI writers return a chunk of data immediately
>>to the browser, then query their DB, whatever, before sending the rest of
>>the response.
>Hmmm, odd. In v1.3 I get CGI output sent as it's generated without the
>benefit of non-blocking pipes. What's changed?

Oh, hang on, scratch that. Turns out the C library's pipe() command uses
named pipes under the covers, for which non-blocking can be and is turned

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  |  He's a very naughty boy!" - Life of Brian |

View raw message