httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: giving CGI the power to flush a socket
Date Fri, 01 Nov 1996 09:30:22 GMT
sameer wrote:
> 	Its been discussed here that nph sucks but people want to use
> nph so the cgi can decide when to flush the socket. One idea I had was
> to have the CGI send a SIGUSR2 or something to the parent process,
> when the flush was desired, so that the parent process would have a
> signal handler that would flush at this point.
> 	What do people think? Is this an evil idea?

It is an evil idea. The trouble is that signals interrupt system calls, and
there's no way of knowing which one it'll interrupt. Apache does not generally
take sufficient care to handle signal interrupted calls, because the usual
outcome of a signal is to abort the connection, so detailed handling is not
required. There are ways around this on systems which support signal blocking
(older ones don't, I think), but would require extensive reworking of the

Two methods I've mentioned before work:

1. The script sends headers specifying a buffer size and timeout, after which
the buffers are flushed. This is low overhead.

2. The script does something akin to server push (i.e. multipart MIME). This
gives very fine control at the expense of the server having to parse the
entire output stream (admittedly probably a very cheap parse - just a string



Ben Laurie                Phone: +44 (181) 994 6435  Email:
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL:
A.L. Digital Ltd,         Apache Group member (
London, England.          Apache-SSL author

View raw message