Date: Wed, 20 Dec 2006 13:18:11 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: 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.0612201308220.23942@sea.ntplx.net> In-Reply-To: <20061220153126.G85384@fledge.watson.org> References: <32874.1165905843@critter.freebsd.dk> <Pine.GSO.4.64.0612121543220.8780@sea.ntplx.net> <200612132010.49601.davidxu@freebsd.org> <Pine.GSO.4.64.0612130918140.13170@sea.ntplx.net> <20061220153126.G85384@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0612201308220.23942>