"Dean Herington" <[EMAIL PROTECTED]> writes:
> >
> > 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
> > as such?
>
> One reason is complexity. If I mark my FDs with O_NONBLOCK, don't I need
to
> wrap a
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
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]':
http://www.has
"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
>
ss 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
> &
aitRead` that I've
> not closed the
> file descriptor. The check never detects a closed file
> descriptor, yet I still get 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 RT
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
> 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 th
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 f