From owner-freebsd-java@FreeBSD.ORG Tue Dec 12 01:09:03 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 9C99F16A40F; Tue, 12 Dec 2006 01:09:03 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CA3943E27; Tue, 12 Dec 2006 01:04:41 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.8/8.13.8/NETPLEX) with ESMTP id kBC15whr006985; Mon, 11 Dec 2006 20:05:58 -0500 (EST) Date: Mon, 11 Dec 2006 20:05:58 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Arne H. Juul" In-Reply-To: Message-ID: 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 X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Mon, 11 Dec 2006 20:05:58 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Kostik Belousov , freebsd-arch@freebsd.org, David Xu , freebsd-java@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 Reply-To: Daniel Eischen List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 01:09:03 -0000 On Tue, 12 Dec 2006, Arne H. Juul wrote: > On Tue, 12 Dec 2006, David Xu wrote: >> On Tuesday 12 December 2006 06:34, Arne H. Juul wrote: >> >>> This is exactly the sort of issue that should be solved by the >>> thread library / kernel threads implementation and not in every >>> threaded application that needs it, in my view. >>> >> It should not be done in new thread library, do you want a bloat >> and error-prone thread library ? Instead if this semantic is really >> necessary, it should be done in kernel. > > Well, it depends on the alternatives. > If a clean kernel implementation is possible - yes please, of course. > If only a complex, error-prone kernel implementation is possible, > I would prefer to have the complexity in the thread library. 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. -- DE