On Thu, 21 Dec 2006, Robert Watson wrote:

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


Yes, I would think so. Solaris behaves this way also, although
there seems to be a bug in Solaris 8 (version tested) in that
select() returns -1 but errno isn't properly set (it is 0).

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