httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan J Kurz <>
Subject Re: SIGPIPE on Solaris 2.5.1
Date Tue, 22 Apr 1997 06:37:00 GMT
Dean writes:
> On Tue, 22 Apr 1997, Nathan J Kurz wrote:
> > Except for CGI's.  I wonder if this bug might explain some of the
> > problems with CGI's not receiving SIGPIPE's when the client closes.
> The most common problem that causes this is that apache alternates between
> blocking reading from the CGI and blocking writing to the client.  If
> the CGI is long running (the only ones we care about this on) it'll just
> sit there blocked on the CGI and not notice the client is gone.  Sockets
> just don't cause SIGPIPE in this case, at least that's been my experience.
> My suggestion is to take Sameer's CGI buffering and tweak so that we've got
> a select() going on both fds in this case.

I agree, SIGPIPE isn't raised until you actually try to write
something to the socket.  But I think this is a different problem.
Solaris's difficulty with SIGPIPE's combined with the current
send_fd_length() causes problems for scripts that print lots of output
and still run for a long time.

For example, consider a Perl script like this:
#! /usr/bin/perl
$| = 1;         # unbuffer STDOUT
print "Content-type: text/html\n\n";
while (1) {
  print "More stuff being pushed<br>\n";

One would think that when you pushed Stop on the browser the script
would get a SIGPIPE and die as soon as a buffer was filled and
written.  Unfortunately, on Solaris 2.5.1 it doesn't ever get that
signal.  Even if you press Stop immediately, until the server Timeout
is reached send_fd_length() keeps trying to throw away input as fast
as your processor will run:

23864 nate     -25    0 2008K 1680K run     3:27 62.73% 62.73% long_push
23797 nate     -15    0 1744K 1304K sleep   1:54 35.22% 35.04% httpd

So while Sameer's CGI patch might help in some circumstances, and
while this is probably a Solaris bug, and while there probably aren't
many CGI's that work like this, it might be worth revisiting the error
handling in send_fd_length() when bwrite() returns a -1 and errno is
not EAGAIN. :)

View raw message