sof at galois.com
Thu Aug 29 12:45:20 EDT 2002
"Dean Herington" <heringto at cs.unc.edu> writes:
> When a thread wants to read from a file descriptor, its logic looks like:
> threadWaitRead (fdToInt fd)
> ([char], 1) <- locked (fdRead fd 1)
> where `locked` obtains and holds the aforementioned lock for the duration
> its argument action.
> Reflecting on the above, I now realize that the recent change
> (/fptools/ghc/rts/Select.c?rev=1.22 in GHC 5.04) to wake up all threads
> select() returns an EBADF error, though well-intentioned, is
> The point of `threadWaitRead` and `threadWaitWrite` is to block the
> thread until it's known that a subsequent call involving the given file
> descriptor will not block. Allowing all threads to continue--even those
> whose file descriptor is not yet ready--allows for exactly the deadlock
> `threadWaitRead` and `threadWaitWrite` are designed to avoid.
The assumption is that FDs are marked as non-blocking, so this won't
be a problem. Do you have a good reason not to have your FDs marked
> I consider it a bug in select() that, when EBADF is reported, the sets of
> "ready" file descriptors are not also reported.
That would be the wrong thing to do, assuming the FD_SETs are in any
way valid when select() returns failure.
More information about the Glasgow-haskell-bugs