Date: Tue, 12 Dec 2006 16:54:19 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Daniel Eischen <deischen@FreeBSD.org> Cc: Kostik Belousov <kostikbel@gmail.com>, "Arne H. Juul" <arnej@pvv.ntnu.no>, freebsd-java@FreeBSD.org, David Xu <davidxu@FreeBSD.org>, freebsd-arch@FreeBSD.org Subject: Re: close() of active socket does not work on FreeBSD 6 Message-ID: <20061212160016.W56465@delplex.bde.org> In-Reply-To: <Pine.GSO.4.64.0612111956110.2938@sea.ntplx.net> References: <Pine.LNX.4.62.0612111535280.32258@decibel.pvv.ntnu.no> <20061211171115.GD311@deviant.kiev.zoral.com.ua> <Pine.LNX.4.62.0612112259050.12159@decibel.pvv.ntnu.no> <200612120816.07608.davidxu@freebsd.org> <Pine.LNX.4.62.0612120142010.30236@decibel.pvv.ntnu.no> <Pine.GSO.4.64.0612111956110.2938@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Dec 2006, Daniel Eischen wrote: > Hacking libthr or libpthread to do this for you is not > an option. They would then look like libc_r since all > fd's accesses would need to be wrapped. If this needs > to be done, it must be in the kernel. > > Common sense leads me to think that a close() should release > threads in IO operations (reads/writes/selects/polls) and > return EBADF or something appropriate. At least when behavior > is not dictated by POSIX or other historical/defactor behavior. It's probably a nightmare in the kernel too. close() starts looking like revoke(), and revoke() has large problems and bugs in this area. At higher levels, revoke() has no support for either waking up or synchronizing with threads in I/O operations on the revoked file; it only tries to force a close on revoked files that are open, but due to reference counting problems it sometimes gets even this wrong. At lower levels, I think only the tty driver even partly understands that a device close() can occur while an (other) thread is in another operation on the device. Of course, most revokes are of ttys so the tty driver needs to understand this more than most. It uses a generation count to detect changes of the open instance. It doesn't wake up the other threads and depends on them checking the generation count. The check occurs mainly in ttysleep() where it is fundamentally incomplete on SMP systems -- there is no synchronization, so after a revoke(), threads running on other CPUs just blunder on like they do in other drivers. Giant locking of the tty driver reduces the problem. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061212160016.W56465>