Re: giving CGI the power to flush a socket

[Ben Laurie <be...@gonzo.ben.algroup.co.uk>]

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
code.

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
match).

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author