httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: require-client functionality
Date Tue, 07 May 1996 21:02:15 GMT
Rob Hartill wrote:
> 
>  
> > Hmmm ... not sure about that, as the 1 is a side effect of the buggy close you
> > added. Can you try this; first, confirm that bclose actually is closing fd 1
> > when you have your close() in http_main.c. Then, take out the close in
> > http_main.c and add an extra close(fb->fd) in bclose() [yeah, I know this
> > should have no effect but it seems to be what is happening] and test again.
> 
> close(1) before the accept solves my problem and bclose returns 0.

What is fb->fd in this case?

> 
> without close(1) = problem
> 
> 2 x close(fb->fd) + no close(1)   = problem + 2nd close returns -1
> fb->fd = 8, so I didn't think that'd work.
> 
> now what?   :-)
> 
> I think we can get away with "close(1)" before the main child
> loop (which works). Is it safe to shutdown the stdout here? I'd
> guess that it is since we only talk to stderr, right?.

Never fix a bug until you understand it. I don't understand this.

> 
> As I said before, the perl CGI needs to close stdout, so this ties
> in with running background processes independently of the parent.

Hmmm ... ah! Got it! The cgi exec cleans up the pool. Which used to close the
socket from the client. In the current version the client socket _is not
registered in the pool_ (jeez!). So it isn't cleaned up. The close(1) causes
it to be coincidentally cleaned when the CGI closes stdout. All is explained.
We can fix the bug - but my supper is nearly ready so there will be a brief
interlude.

Cheers,

Ben.

> 
> Was 1.1b0 giving CGI dup'ed versions of stdout that may have the same
> effect?  I vaguely remember some dup(1), close(1) type commands in the
> really old apache/ncsa code.
> 
> 
> rob

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

Mime
View raw message