Date: Tue, 26 Jun 2007 02:52:45 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: [6.x] problem with AIO, non-blocking sockets on freebSD and IE7 on windows. Message-ID: <20070626023944.M82078@besplex.bde.org> In-Reply-To: <467C727D.4060703@elischer.org> References: <467C727D.4060703@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Jun 2007, Julian Elischer wrote: > If one has an event-driven process that accepts tcp connections, one needs to > set eh non-blocking socket option and use kqueue or similar to schedule work. > > This is ok for data transfers, however when it comes to the close() call > there is a problem. The problem in in the following code in so_close() > > > if (so->so_options & SO_LINGER) { > if ((so->so_state & SS_ISDISCONNECTING) && > (so->so_state & SS_NBIO)) > goto drop; > ... > drop: > [ continues on to destroy socket ] > > > because SS_NBIO is set, the socket acts as if SO_LINGER was set, with a > timeout of 0. > the result of this, is the following behaviour: [ patckets in flight get lost ] This seems to be the correct behaviour. The application doesn't care about its data and/or wants to close the descriptor without blocking, so it doesn't turn off the blocking flag and/or wait for i/o to complete (so that it can see if the i/o actually worked) before calling close(). I implemented this behaviour for tty drivers in FreeBSD. Old BSD tty drivers didn't check the nonblocking flag and didn't have a timeout, so close() on tty devices tended to hang forever (normally at long weekends) even for closes that should have been nonblocking. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070626023944.M82078>