Bug in IO libraries when sending data through a pipe?

[Volker Wysk]

Hi

On 21 Mar 2002, Jens Petersen wrote:
> Volker Wysk <post@volker-wysk.de> writes:
> > POpen-1.0.0 contains the same bug which I made. It doesn't ensure that
> > the values which are needed after the call of forkProcess, before that
> > of executeFile, are fully evaluated. So, if they are read lazily from a
> > stream, the newly spawned child process reads data from a stream which
> > it shares with its parent, making it disappear from the parent's input.
> > In this situation, this sure isn't intended.
>
> Perhaps you could give an explicit example?

I haven't tried it, but it's exactly the same thing.

> > Inserting the following lines just before the line "pid <- forkProcess",
> > in POpen.hs, would force the corresponding values to be evaluated, so no
> > data will be lost.
> >
> >     seq (length path) $ seq (sum (map length args)) $ return ()
> >     when (isJust env) $ seq (sum (map (\(a,b) -> length a + length b)
> >                                       (fromJust env))) $ return ()
> >     when (isJust dir) $ seq (length (fromJust dir)) $ return ()
>
> Hmmm, I don't really see why this is necessary.  Don't the
> lazy values of "path", "env" and "dir" just get evaluated
> when they're needed here as normal?  (If what you say is
> true though it would be simpler just to use "$!" or "!"s for
> strict evaluation I guess.)

Yes, and that's *after* forkProcess. So when they are computed from
the lazily read contents of a stream, the newly spawned child will read
data from a stream which it shares with its parent.


> > I'm also not sure what this part is supposed to do:
> >
> >     inr <- if (isJust inpt) then
> > 	     do
> > 	     (inr', inw) <- createPipe
> > 	     hin <- fdToHandle inw
> > 	     hPutStr hin $ fromJust inpt
> > 	     hClose hin
> > 	     return $ Just inr'
> > 	    else
> > 	    return Nothing
>
> It returns the output end of a pipe containing the input
> string if one is given.
>
> > Doesn't it write the input data to a pipe which no process reads
> > from..??
>
> Nope, "doTheBusiness" dup2's it to the stdin of the subprocess: [...]

But hPutStr, followed by hClose, won't complete until all the input string
has been written, while no process is listening.


Volker