httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Spinning httpds - One Solution
Date Fri, 21 Aug 1998 19:49:56 GMT
On Fri, 21 Aug 1998, Rasmus Lerdorf wrote:

> > >Aha!  That answers a long outstanding headscratcher for me.  Is there a
> > >good reason for r->connection->aborted not getting set if a client closes
> > >the connection irregardless of the timeout state?  It would certainly make
> > >life easier on me in PHP land if this was the case.
> > 
> > Because r->connection->aborted indicates that the server has decided to
> > abort the connection, not that the client has closed it.  We could set

Not entirely.  The problem is that on a SIGPIPE it is set if within a soft
timeout, but it sure isn't the server deciding to close the connection.

> > it on client close as well, but only within the routines that read and
> > write to the connection directly (ap_r*), but then we'd have to change
> > those routines to actually look at the return value instead of assuming
> > that the caller will handle it.
> Well, not much difference between the caller checking this return value
> and the functions themselves doing it.  I think I might prefer leaving it
> up to the caller actually.  In PHP2 I was checking all my write return
> values, but when I did the PHP3 rewrite and dropped Apache-1.1 support I
> figured I could use r->connection->aborted without realizing that it
> wasn't quite that simple.  
> It looks like going back to checking the return values is the best idea
> and forgetting about r->connection->aborted.  
> I guess the only remaining question is whether I should trap SIGPIPE in
> case it does occurr and thus avoid having Apache longjmp out before I am
> ready to let it do so?  

Use a soft_timeout instead of a hard_timeout.  That also, of course,
impacts your timeouts but in theory you should have the same issues with
timeouts that you may have with SIGPIPEs WRT "before I am ready".

View raw message