From owner-freebsd-java@FreeBSD.ORG Tue Dec 12 05:54:25 2006 Return-Path: X-Original-To: freebsd-java@FreeBSD.org Delivered-To: freebsd-java@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DFEC16A403; Tue, 12 Dec 2006 05:54:25 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13CA443CAC; Tue, 12 Dec 2006 05:53:04 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.2.163]) by mailout2.pacific.net.au (Postfix) with ESMTP id 589B21291E2; Tue, 12 Dec 2006 16:54:20 +1100 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (Postfix) with ESMTP id 11AB527432; Tue, 12 Dec 2006 16:54:19 +1100 (EST) Date: Tue, 12 Dec 2006 16:54:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Daniel Eischen In-Reply-To: Message-ID: <20061212160016.W56465@delplex.bde.org> References: <20061211171115.GD311@deviant.kiev.zoral.com.ua> <200612120816.07608.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , "Arne H. Juul" , freebsd-java@FreeBSD.org, David Xu , freebsd-arch@FreeBSD.org Subject: Re: close() of active socket does not work on FreeBSD 6 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 05:54:25 -0000 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