atom feed32 messages in org.freebsd.freebsd-archclose() of active socket does not wor...
FromSent OnAttachments
Kostik BelousovDec 11, 2006 9:11 am 
Arne H. JuulDec 11, 2006 2:40 pm 
David XuDec 11, 2006 4:15 pm 
Arne H. JuulDec 11, 2006 4:50 pm 
David XuDec 11, 2006 5:05 pm 
Daniel EischenDec 11, 2006 5:08 pm 
Bruce EvansDec 11, 2006 9:54 pm 
Poul-Henning KampDec 11, 2006 10:43 pm 
Daniel EischenDec 12, 2006 5:21 am 
Kostik BelousovDec 12, 2006 5:59 am 
Daniel EischenDec 12, 2006 6:24 am 
Daniel EischenDec 12, 2006 6:35 am 
Kostik BelousovDec 12, 2006 6:38 am 
Daniel EischenDec 12, 2006 12:49 pm 
David XuDec 12, 2006 3:29 pm 
Bruce EvansDec 12, 2006 7:28 pm 
Julian ElischerDec 12, 2006 11:12 pm 
Bruce EvansDec 13, 2006 3:28 am 
David XuDec 13, 2006 4:10 am 
Daniel EischenDec 13, 2006 6:23 am 
Robert WatsonDec 20, 2006 8:22 am 
Daniel EischenDec 20, 2006 10:28 am 
David XuDec 20, 2006 4:19 pm 
Julian ElischerDec 21, 2006 5:02 am 
Robert WatsonDec 21, 2006 5:46 am 
Robert WatsonDec 21, 2006 7:21 am 
Daniel EischenDec 21, 2006 9:15 am 
John-Mark GurneyDec 21, 2006 6:17 pm 
David XuDec 21, 2006 6:42 pm 
Daniel EischenDec 21, 2006 7:35 pm 
John-Mark GurneyDec 21, 2006 8:07 pm 
Daniel EischenDec 21, 2006 8:16 pm 
Subject:close() of active socket does not work on FreeBSD 6
From:David Xu (davi@freebsd.org)
Date:Dec 20, 2006 4:19:54 pm
List:org.freebsd.freebsd-arch

On Thursday 21 December 2006 02:18, Daniel Eischen wrote:

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.

I think the main concern is if we will record every thread using a fd, that means, when you call read() on a fd, you record your thread pointer into the fd's thread list, when one wants to close the fd, it has to notify all the threads in the list, set a flag for each thread, the flag indicates a thread is interrupted because the fd was closed, when the thread returns from deep code path to read() syscall, it should check the flag, and return EBADF to user if it was set. whatever, a reserved signal or TDF_INTERRUPT may interrupt a thread. but since there are many file operations, I don't know if we are willing to pay such overheads to every file syscall, extra locking is not welcomed.