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>