httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: [PATCH] Handle timeouts in buffers as well as connection
Date Sun, 20 Apr 1997 20:56:26 GMT

This patch, with these additional changes, seems to be working and 
even shows some promise of reducing the swap usage issues I have 

However, it does seem that something has gone ary WRT Content 
Length and Keepalives. (Assuming that Netscape uses 
"Content-Length" to determine transfer rate) Netscape shows
significantly  reduced throughput in it's progress meter, but other
tests seem to show that the transfer rate remains the same. I'm not
entirely sure I can blame it on this patch, but at this time can
narrow it down between Dean's graceful restart patches and this one.

> I spent the night trying to understand why we don't get a SIGPIPE
> on Solaris 2.5 after the user presses Stop on the client.  According
> to netstat, the socket is closing properly, but we just continue writing
> until the request times out (my patch is needed for the time out)
> because the server process never receives a SIGPIPE and the write
> never returns EPIPE.  As far as I can tell, Solaris is just broken
> in this regard.
> However, in the process, I did find a few more problems with the
> timeout code, so I have re-generated my patch below.  This patch does
> fix the problem in PR#373, though we'd be better off with a SIGPIPE.
> If a soft timeout (or lingerout) occurs while trying to flush a
> buffer or write inside buff.c or fread'ing from a CGI's output,
> then the timeout would be ignored.  This fix is rather nasty,
> since what we would really like to do is flush the output if we
> timeout on a read, but we can't do that without differentiating
> between read and write timeouts, and we can't do that without
> rewriting most of the server.
> What we really need is a global (per-thread) timeout that sets a
> single flag, and then have all of our code check for that flag and
> recover gracefully based upon what it was trying to do at the time.
> However, that might be subject to race conditions as well, so we
> might just need to replace all of our generic timeouts with more
> sophisticated timeouts, each with its own sigsetjmp handling.
> Something to remember for 1.2.
> .....Roy

View raw message