Date: Thu, 21 Dec 2006 23:16:44 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Julian Elischer <jelischer@ironport.com>, Robert Watson <rwatson@freebsd.org>, David Xu <davidxu@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: close() of active socket does not work on FreeBSD 6 Message-ID: <Pine.GSO.4.64.0612212310080.2302@sea.ntplx.net> In-Reply-To: <20061222040738.GD4982@funkthat.com> References: <32874.1165905843@critter.freebsd.dk> <20061220153126.G85384@fledge.watson.org> <Pine.GSO.4.64.0612201308220.23942@sea.ntplx.net> <200612210820.09955.davidxu@freebsd.org> <4589E7D2.9010608@ironport.com> <20061221152115.U83974@fledge.watson.org> <20061222020101.GC4982@funkthat.com> <Pine.GSO.4.64.0612212227410.2250@sea.ntplx.net> <20061222040738.GD4982@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0612212310080.2302>