close() of active socket does not work on FreeBSD 6
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.
More information about the freebsd-arch