System.Process

[David Roundy]

On Mon, Jun 21, 2004 at 01:28:41PM +0100, Simon Marlow wrote:
> On 20 June 2004 10:57, David Roundy wrote:
> > Just to make sure I understand things... could runProcess be
> > implemented in terms of runInteractive as below? Not that this would
> > be wise--I imagine it goes the other way around--but I want to be
> > sure that I understand how I'd want to modify things, for example if
> > I wanted to interactively write to a process, but have its output
> > logged straight to a file. 
> > 
> > runProcess c as menv (Just inh) (Just outh) (Just errh) =
> >   do (iinh, iouth, ierrh, ph) <- runInteractiveProcess c as menv
> >      instr <- hGetContents inh
> >      outstr <- hGetContents iouth
> >      errstr <- hGetContents ierrh
> >      forkIO $ do hPutStr outh outstr
> >                  hClose outh
> >      forkIO $ do hPutStr errh errstr
> >                  hClose errh
> >      forkIO $ do hPutStr iinh instr
> >                  hClose iinh
> >      return ph
> 
> Hmm, looks like that might work, yes.  It's not quite the same, though:
> in your version, the inh Handle ends up semi-closed, whereas in the
> current runProcess implementation it is closed immediately.  In your
> implementation, the outh and errh handles are closed when all the output
> has been written to them; in my implementaiton they are closed
> immediately.  (I just noticed that my Windows implementation differs
> from the Unix implementation in this respect).
>
> Closing these handles immediately seems more deterministic, but I'm not
> sure which is the most "useful" behaviour.

Hmmmm.  I see... I like the idea of having the handles closed immediately.
Your implementation (unlike mine) also means that the haskell program will
no longer be involved in the IO of the child process, which also seems like
a very good thing, both efficiency-wise and stability-wise.
-- 
David Roundy
http://www.abridgegame.org