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

Bruce Evans bde at zeta.org.au
Wed Dec 13 03:28:29 PST 2006


On Tue, 12 Dec 2006, Julian Elischer wrote:

> Bruce Evans wrote:
>> A signal would be fast enough for revoke() since revoke() is not used
>> much, and would work well if the signal could be sent, and is unmaskable,
>> and all device drivers catch signals (oops, all of them act like
>> ...
>> However, I think there is no way to determine which threads are using
>> an fd short of doing the equivalent of fstat(1) searching throuhj kmem.
>> Kernel data structures just aren't set up to do this search efficiently,
>> and shouldn't be bloated to do it.
>
> that's processes.. which thread in the process is the one that is currently 
> waiting on the socket?

Do you mean that this wouldn't work the signal would need to be per-thread
but signals are per-process?  Aren't there per-thread signals now?

It's not just one thread, at least for general files.  There can be any
number.  I just remembered that SIGIO delivery has problems near here.
There is some i/o on a device, and the kernel has to figure out all
open fd's on the device with O_ASYNC set on the open file of the fd.  It
has difficulty doing this, even with some data structures pointing from
the device back to the processes.  In theory there can be any number of
fd's with the same open file and the signal should be broadcast to the
processes owning these fd's).  This is still simpler than signaling
threads in i/o functions since the signal is broadcast.

I said that something like fstat(1) groping in kmem is needed to find all
the relevant threads.  That is nowhere near enough -- fstat cannot tell
which threads are currently in i/o functions.  Something closer to what
debuggers do is needed -- stop all threads and stack trace them all to
see where they are :-).

Bruce


More information about the freebsd-arch mailing list