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

David Xu wrote:
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.

I think you are only intersted in treads that are sleeping..
so you allow a sleeping thread to save a pointer to the fd (or whatever) on which it is sleeping, along with the sleep address.

items that are not sleeping are either already returning, or are going to sleep, in which case they can check at that time.


Regards,
David Xu
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: close() of active socket does not work on FreeBSD 6
    ... of the other reasons why this isn't a good idea. ... serious re-working of how we implement file descriptor reference counting ... signals interrupting threads waiting on IO. ... the fd, it has to notify all the threads in the list, set a flag ...
    (freebsd-arch)
  • Re: close() Interrupted By Signal (Resumption Fails)
    ... close still closes a file descriptor. ... even without a signal interrupting the call, ... a program with no signals: ... Linux allows you to restart connectwithout having to ...
    (comp.unix.programmer)
  • Re: close() Interrupted By Signal (Resumption Fails)
    ... close still closes a file descriptor. ... I found one mention that Linux does not return EINTR for close ... even without a signal interrupting the call, ... a program with no signals: ...
    (comp.unix.programmer)
  • Re: behavior of accept(2) in multithreaded application
    ... David Schwartz wrote: ... A system thread runs, ... same file descriptor you closed in step 2. ... You cannot guarantee that during that interval, no other thread will run and cause the descriptor to be reused. ...
    (comp.unix.programmer)
  • Re: close() of active socket does not work on FreeBSD 6
    ... 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. ... 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. ... signals interrupting threads waiting on IO. ...
    (freebsd-arch)