From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 13:21:20 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B479916A417; Tue, 12 Dec 2006 13:21:20 +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 52E3443DBA; Tue, 12 Dec 2006 13:17:24 +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 kBCDIWqu003219; Tue, 12 Dec 2006 08:18:33 -0500 (EST) Date: Tue, 12 Dec 2006 08:18:32 -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]); Tue, 12 Dec 2006 08:18:33 -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-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2006 13:21:20 -0000 On Mon, 11 Dec 2006, Daniel Eischen wrote: > 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. It's also couldn't be entirely solved by fixing it in the threads library. You could still have a non-threaded application that waits on a read operation, but receives a signal and closes the socket in the signal handler. -- DE