From owner-freebsd-arch@FreeBSD.ORG Fri Dec 22 04:16:45 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 E028A16A403; Fri, 22 Dec 2006 04:16:45 +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 8661E13C442; Fri, 22 Dec 2006 04:16:45 +0000 (UTC) (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 kBM4GiRX028600; Thu, 21 Dec 2006 23:16:44 -0500 (EST) Date: Thu, 21 Dec 2006 23:16:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John-Mark Gurney In-Reply-To: <20061222040738.GD4982@funkthat.com> Message-ID: 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> <20061222040738.GD4982@funkthat.com> 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]); Thu, 21 Dec 2006 23:16:44 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: Julian Elischer , Robert Watson , 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: Fri, 22 Dec 2006 04:16:46 -0000 On Thu, 21 Dec 2006, John-Mark Gurney wrote: > Daniel Eischen wrote this message on Thu, Dec 21, 2006 at 22:35 -0500: >> On Thu, 21 Dec 2006, John-Mark Gurney wrote: >> >>> 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 also, but hanging without return isn't very detectable. > > It's a lot more detectable than working 99% more of the time and > failing when things get correupted due to a race.. :) I dunno, I think returning an appropriate error on the actual call(s) that are problematic is easier to detect than trying to figure out just what is causing the hang, corruption, whatever. Perhaps I mean "debug" instead of "detect". >> The best thing to do is to tell the programmer that he is doing >> something stupid, and returning with an error is the way that >> it is typically done. Solaris seems to have jumped through > > As long as it's EDOOFUS... I don't see any other error that would > be approriate... EBADF. That's what Solaris returns and makes more sense to me. >> some hoops to achieve this behavior, so I doubt it is without >> merit. OTOH, I'm not going to argue that it is one of the >> more important things we should be worried about ;-) > > As long as it doesn't cost much more to do it... Hanging is just as > good of an indication as returning an error... And I'd say it's better > as it forces the buggy software to be fixed as opposed to simply ignoring > the error which is likely what the programmer will do... Yes, unfortunately, ignoring the error would probably happen a lot. -- DE