Hello, Hrm, setting the LineBuffering mode had the side-effect of setting the underlying file description to non-blocking mode. When the executeFile process took over, it would die with an error about 'standard input temporarily unavailable'. So, ignore that.
j. At Wed, 28 Feb 2007 15:23:53 -0600, John Goerzen wrote: > > On Wed, Feb 28, 2007 at 01:06:25PM -0800, Jeremy Shaw wrote: > > Hello, > > > > Your first problem is just a line buffering issue. You need to > > explicitly set the line buffer inside the child processes: > > > > redir fstdin stdInput > > hSetBuffering stdin LineBuffering > > redir fstdout stdOutput > > hSetBuffering stdout LineBuffering > > Hi Jeremy, > > First, many thanks for looking into this. > > That doesn't make sense to me, since these aren't used for anything in > Haskell prior to the call to executeFile. The Haskell buffers should > just disappear, since the Haskell process disappears, right? > > > Once you fix that you will encounter some new race condition type > > bugs. These bugs will show up, even *without* the -threaded flag. > > Hrm, could you point out a couple? I'm developing as many unit tests as > I can, and haven't had any problem running them under a non-threaded > GHC. > > I am aware that the debug statements can write over each other at some > cases, or even get inserted into the pipeline in a few situations, but > these are only used in exceptional cases and will generally be removed > from the code before too long. > > Other than that, I think I've got it OK. My unit tests are covering > singleton commands and 2-4 commands in a pipe, including various > permutations of calls to external programs and Haskell functions. > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users