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

[Julian Elischer]

Bruce Evans wrote:
> On Wed, 13 Dec 2006, David Xu wrote:
> 
>> On Wednesday 13 December 2006 04:49, Daniel Eischen wrote:
>>> On Tue, 12 Dec 2006, Poul-Henning Kamp wrote:
>>>> In message <20061212160016.W56465 at delplex.bde.org>, Bruce Evans writes:
>>>>> On Mon, 11 Dec 2006, Daniel Eischen wrote:
>>>>>
>>>>> It's probably a nightmare in the kernel too.  close() starts looking
>>>>> like revoke(), and revoke() has large problems and bugs in this area.
>>>>
>>>> There is the distinctive difference that revoke() operates on a name
>>>> and close() on a filedescriptor, but otherwise I agree.
>>>
>>> Well, if threads waiting on IO are interruptable by signals,
>>> can't we make a new signal that's only used by the kernel
>>> and send it to all threads waiting on IO for that descriptor?
>>> When it gets out to actually setup the signal handler, it
>>> just resumes like it is returning from an SA_RESTART signal
>>> handler (which according to another posting would reissue
>>> the IO command and get EBADF).
>>
>> Stop using signal, it is slow for threaded process, first you don't
>> know which threads are using the descriptor, second, you have
>> to run long code path in kernel signal code to find and deliver
>> the signals to all interested threads, that is too expensive for
>> benchmark like apache benchmark.
> 
> 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
> applications whose signal catching function just sets a flag, except
> while they sleep, so they have the usual problems with just setting a
> flag -- they may run for too long before actually using the setting).
> 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?

> 
> For close() on non-devices, there is the additional problem of infinite
> disk waits due to things like nfs servers down and bugs.  Then signals
> don't work and you wouldn't like close() by a thread trying to clean
> up the problem to hang too.  Otherwise close()/revoke() would be a good
> way to cancel an infinite disk wait.
> 
> Bruce
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"