httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: lingering close
Date Sat, 18 Jan 1997 21:33:46 GMT

I agree. I just raised the same issue with Marc suggesting that we
could even be tripping over a race condition in the kernel since
the close is going to do a shutdown as well.

To restate the suggested fixes I just sent to Marc:

* Call kill_timeouts() before entering lingering_close().

* If the first call to shutdown() fails, close() for good measure
  and return;

* Initialize the timeval struct to zeros since we should just be
  polling here. (Jim questioned this)

* Finally, just call close(). close() should do a shutdown() and it
  seems like a likely place for a race condition in the kernel that
  could tickle unknown kernel bugs.

> I'm curious why the second shutdown() is even required.  Just closing the
> socket should be sufficient at that point.  There's also the possibility
> of an os bug where doing shutdown(sd,2) after having done shutdown(sd,1) 
> puts the socket into a screwed state.  So if the second shutdown is really
> necessary for some reason then try changing it to shutdown(sd,0).
> Dean
> On Sat, 18 Jan 1997, Randy Terbush wrote:
> > 
> > I would like to compare notes with others who are debugging this.
> > Rather than flood the list with what, at this point, is speculative
> > discussion, mail me privately and we'll begin building an alias for
> > whomever is interested.
> > 
> > I've looked at a lot of debug code coming from the area that I feel
> > shows a problem.
> > 
> > One thing that I have run across as I pour through the Steven's TCP
> > books is that it seems to me that FIN_WAIT_2 is a state passed off
> > to the kernel, and subsequent calls to shutdown() will not move
> > the state to TIME_WAIT. This leads me to think that unless the
> > kernel supports timeouts of FIN_WAIT_2, we are hurting ourselves
> > by using the half-close.
> > 
> > It also looks like we could write our own shutdown() that is a
> > bit smarter. Currently, I think that there is a race condition
> > present that allows us to call shutdown on a connection that is
> > no longer present. No biggie. But could help us debug this if we
> > do a better job of limiting the sockets that actually make it to
> > this routine.
> > 
> > 
> > 
> > 

View raw message