This patch, with these additional changes, seems to be working and
even shows some promise of reducing the swap usage issues I have
seen.
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
>
>
|