the select() failure.
Hmm, then I don't know what is going wrong. Perhaps you could reduce it
to a small example and post it?
I'm assuming that the RTS's select() is done on the sets of file
descriptors involved in current `threadWaitRead` and `threadWaitWrite`
calls. Is that true? Are there other
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?
The file descriptor is the read
Dean Herington [EMAIL PROTECTED] 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
of
its argument
In local.glasgow-haskell-bugs, you wrote:
It sure would simplify my program if I could fork a process and not have
auxiliary threads persist in the child. Could this option be provided by
GHC RTS in a semantically sound way?
On a recent GHC you can try 'forkProcess[Prim]':
Sigbjorn Finne wrote:
Dean Herington [EMAIL PROTECTED] 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
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
On Wed, 28 Aug 2002, Simon Marlow wrote:
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
