From owner-freebsd-arch@FreeBSD.ORG Fri Dec 22 02:43:15 2006 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 37E8816A407; Fri, 22 Dec 2006 02:43:11 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <458B4641.5080808@freebsd.org> Date: Fri, 22 Dec 2006 10:43:13 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <32874.1165905843@critter.freebsd.dk> <20061220153126.G85384@fledge.watson.org> <200612210820.09955.davidxu@freebsd.org> <4589E7D2.9010608@ironport.com> <20061221152115.U83974@fledge.watson.org> <20061222020101.GC4982@funkthat.com> In-Reply-To: <20061222020101.GC4982@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Julian Elischer , Robert Watson , 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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2006 02:43:15 -0000 John-Mark Gurney wrote: > Robert Watson wrote this message on Thu, Dec 21, 2006 at 15:22 +0000: > >>>I think you are only intersted in treads that are sleeping.. so you allow >>>a sleeping thread to save a pointer to the fd (or whatever) on which it is >>>sleeping, along with the sleep address. >>> >>>items that are not sleeping are either already returning, or are going to >>>sleep, in which case they can check at that time. >> >>Hence my question about select and poll: should they throw an exception >>state when a file descriptor is closed out from under them? They often >>sleep on hundreds or thousands of file descriptors, and not just one. > > > IMO, your program is buggy if you close the file descriptor before > everything is out of the kernel wrt the fd... It means that your close > statement isn't waiting for things to be cleanly shut down, and that > you still have dangling reference counts to the parts of the code that > is in the kernel... > > I used to expect something similar w/ an kqueue based event driven > web server, and found that I had bugs due to assuming that I could > close it whenever I want... What happens if you close the fd between > the time select returns and you process it? What happens if the fd > gets closed, and another thread (or an earlier fd that accepts > connections) reuses that fd? And then youre state machine isn't read > to get an event since it isn't suppose to get one yet... > > The kernel isn't buggy wrt closing a fd when another thread is using > it, it's the program that's buggy... > I agree with you here, as I said before, kernel may can do things correctly, but user code has to struggle with race condition between multiple threads, so if user code still has to work out a way to avoid many race conditions, why don't they just use a signal to interrupt target thread and do synchronization between threads. The requested extra close() feature seems to be a wrongly defined problem. Regards, David Xu