> I have a program that is suffering a select() failure. It prints:
>
> 9
> select: Bad file descriptor
> Fed: fatal error: select failed
>
> From looking at some RTS sources, the 9 apparently represents
> errno EBADF
> (bad file descriptor). Does that mean that my program is
> somehow closing
> one or more file descriptors between when the select() starts
> and when it
> finishes?
This can arise if you do one of the operations threadWaitRead or
threadWaitWrite on a file descriptor that is closed. Sigbjorn recently
modified the select() code so that it wouldn't fail in such an ugly way;
now it just wakes up all the threads that were doing select() in the
hope that the one with a bad file descriptor in its hands will discover
it some other way (the real problem is that select() doesn't tell us
which file desriptors were bad/closed when it fails).
Anyway, you should avoid this scenario if at all possible, since the
current fall-back method of waking up all the threads could be quite
expensive.
> Unfortunately, select() (and hence the GHC RTS) doesn't
> identify the bad
> descriptor(s). Here's where I suspect my program may be
> going awry. The
> main process creates a pipe. The process then forks. The
> parent closes
> the pipe's read descriptor immediately. The child soon goes
> to read from
> the pipe, using threadWaitRead followed by fdRead. The child process
> suffers the select failure shown above.
So.. I take it the child shouldn't really be reading from a closed file
descriptor?
> By the way, why shouldn't such a "fatal error" in the RTS raise an
> exception that I can catch in my program? I could then
> determine at least
> which thread in which process suffered the error.
A 'fatal error' in the RTS usually means some kind of internal error
which it isn't possible to recover from. Hence the term "fatal" :-)
I've changed the wording in my copy to make it more clear that these
errors are internal and normally indicate a bug.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
