From owner-freebsd-arch@FreeBSD.ORG Wed Dec 20 18:28:22 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 8482916A407 for ; Wed, 20 Dec 2006 18:28:22 +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 D906043C9F for ; Wed, 20 Dec 2006 18:28:21 +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 kBKIIBUN022183; Wed, 20 Dec 2006 13:18:11 -0500 (EST) Date: Wed, 20 Dec 2006 13:18:11 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Robert Watson In-Reply-To: <20061220153126.G85384@fledge.watson.org> Message-ID: References: <32874.1165905843@critter.freebsd.dk> <200612132010.49601.davidxu@freebsd.org> <20061220153126.G85384@fledge.watson.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]); Wed, 20 Dec 2006 13:18:11 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: David Xu , freebsd-arch@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: Wed, 20 Dec 2006 18:28:22 -0000 On Wed, 20 Dec 2006, Robert Watson wrote: > > On Wed, 13 Dec 2006, Daniel Eischen wrote: > >> >> Anyway, this was just a thought/idea. I don't mean to argue against any of >> the other reasons why this isn't a good idea. > > Whatever may be implemented to solve this issue will require a fairly serious > re-working of how we implement file descriptor reference counting in the > kernel. Do you propose similar "cancellation" of other system calls blocked > on the file descriptor, including select(), etc? Typically these system > calls interact with the underlying object associated with the file > descriptor, not the file descriptor itself, and often, they act directly on > the object and release the file descriptor before performing their operation. > I think before we can put any reasonable implementation proposal on the > table, we need a clear set of requirements: [ ... ] > While providing Solaris-like semantics here makes some amount of sense, this > is a very tricky area, and one where we're still refining performance > behavior, reference counting behavior, etc. I don't think there will be any > easy answers, and we need to think through the semantic and performance > implications of any change very carefully before starting to implement. I don't think the behavior here has to be any different that what we currently (or desire to) do with regard to (unblocked) signals interrupting threads waiting on IO. You can spend a lot of time thinking about how close() should affect IO operations on the same file descriptor, but a very simple approach is to treat them the same as if the operations were interrupted by a signal. I'm not suggesting it is implemented the same way, just that it seems to make a lot of sense to me that the behavior is consistent between the two. -- DE