Message-ID: <37B87E46.6DDF37D2@algroup.co.uk>
Date: Mon, 16 Aug 1999 22:10:30 +0100
From: Ben Laurie <ben@algroup.co.uk>
Organization: A.L. Group plc
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: IOL and send_fb
References: <Pine.LNX.3.96dg4.990816135129.1644D-100000@twinlark.arctic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Dean Gaudet wrote:
> 
> On Mon, 16 Aug 1999, Ben Laurie wrote:
> 
> > OK, I sort of get this, but... it seems to me that this won't timeout
> > CGIs (which it should, right?) ... if the CGI never says anything, we
> > hang forever, no?
> 
> before the blocking read the loop sets the timeout on the CGI BUFF back
> to the appropriate amount (which can be different from the timeout for
> the client now, btw).

I've just realised that timeout == 0 means don't wait at all, not wait
forever. Given this, isn't the non-blocking thing redundant (i.e.
timeout == 0 implies nonblock)?

> > Seems to me that the non-blocking and timeout requirements of old are
> > confusing the issue. What we want is that both reads and writes time
> > out, and block until they do, right? Or am I missing something?
> 
> The only reason the non-blocking bit is in there is so that the code
> can bflush the client socket before blocking on the read... that
> way CGIs which stutter their output will stutter all the way to the
> client.

Got it. I think.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi