On a side note, some developers like myself, would love to see all stderr emitted from
a cgi to be read into it's own bucket so modules can do things with the stderr data --
aka a stderr_filter hook.
Such as:
- using stderr as an apache control channel. A cgi module can throttle up or
throttle down apache if a backend service is down...
- escalation of cgi errors in scripts (send an email here...write a log
there...etc.)
- making html based error reports displayed by a javascript popup HTML footer.
- etc.
Maybe it'll help solve this buffering issue.
> -----Original Message-----
> From: Cliff Woolley [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, December 23, 2002 10:57 PM
> To: [EMAIL PROTECTED]; Greg Stein
> Subject: Re: CGI hosed in v2.0.43
>
> On Mon, 23 Dec 2002, Graham Leggett wrote:
>
> > The script gets as far as running cvs, which does part of what it needs
> > to do, and then hangs solid. No errors of any kind are logged in the
> > error log. The request eventually times out completely.
>
> We talked about this problem at length at the hackathon. There's a
> deadlock condition in 2.0's CGI handling (among others) that happens when
> various stdio buffers fill up at the wrong time. If the stderr buffer
> fills up while Apache is trying to read from stdout, for example. Greg
> Stein could explain it better than I can.
>
> Bottom line: I don't know that there's much we can do about this right
> now, but it is a known problem. If you're careful to read from stdin
> frequently and write to stdout/stderr in reasonably small chunks in your
> CGI, I *think* you can work around it.
>
> --Cliff
>
