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 20:12:39 GMT
Chuck Murcko wrote:
> 
> Ben Laurie liltingly intones:
> > 
> > > > > 3) Background CGI scripts never close connections, due to some unforseen
> > > > >    effects in either bclose() or bflush().
> > > > 
> > > > Yeah, this is a weird one ... I've taken a look at the logic and can see
no
> > > > difference between "old" and "new" ... except that the old versions erroneously
> > > > closed the socket twice (on platforms that don't require dup()) or in
the
> > > > opposite order (on platforms that do require dup()). Strangest of all
is that
> > > > a close(1) seems to cure it [can whoever was looking into this confirm
that?].
> > > 
> > > Yes, I was closing '1' and that fixed it.
> > > 
> > > Note that the CGI script must close STDOUT in order for this to work, so
> > > there's a connection there.
> > 
> > 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.
> > 
> Is something like fcntl(d, F_SETFD, 1) needed here, to guarantee that the
> fd is closed? From the 4.4BSD close() man page:
> 
>      When a process forks (see fork(2)),  all descriptors for the new child
>      process reference the same objects as they did in the parent before the
>      fork.  If a new process is then to be run using execve(2),  the process
>      would normally inherit these descriptors.  Most of the descriptors can be
>      rearranged with dup2(2) or deleted with close() before the execve is at-
>      tempted, but if some of these descriptors will still be needed if the ex-
>      ecve fails, it is necessary to arrange for them to be closed if the ex-
>      ecve succeeds.  For this reason, the call ``fcntl(d, F_SETFD, 1)'' is
>      provided, which arranges that a descriptor will be closed after a suc-
>      cessful execve; the call ``fcntl(d, F_SETFD, 0)'' restores the default,
>      which is to not close the descriptor.

As I said before, the fact the file descriptor is a 1 is spurious (the 1 is
simply the most likely return value from select()). The "real" 1 gets closed
before the first connection is accepted. The only logical explanation (captain)
is that for some strange reason two closes work better than one (or the first
close isn't working, somehow I think this is more likely, but I can't see how).

Cheers,

Ben.

> 
> chuck
> Chuck Murcko	N2K Inc.	Wayne PA	chuck@telebase.com
> And now, on a lighter note:
> "Even if you're on the right track, you'll get run over if you just sit
> there."
> 		-- Will Rogers

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