On Wed, 20 Dec 2006, Julian Elischer wrote:

>> 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.

Hence my question about select and poll: should they throw an exception state
when a file descriptor is closed out from under them? They often sleep on
hundreds or thousands of file descriptors, and not just one.

Robert N M Watson
Computer Laboratory
University of Cambridge
freebsd-arch@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"