close() of active socket does not work on FreeBSD 6

Daniel Eischen deischen at freebsd.org
Wed Dec 20 10:28:22 PST 2006


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


More information about the freebsd-arch mailing list