Win32 process spawning, POpen and Hugs, revisited

[Graham Klyne]

Simon,

Further to my previous message, this abstraction looks reasonable to me.

If I ever manage to get the POpen module working, I think the code will 
adapt very easily to most of this interface.  I do think your naming is 
more helpful.

One area where I'm wary:  your runInteractiveProcess returns a process 
handle, which can be used for further synchronization with the offspring 
process.  I wonder if (a) this is really needed, and (b) if it might expose 
some awkward interactions with the interactive I/O streams.  I don't have a 
particular problem in mind, just concerned that this might turn tricky in 
the future.

#g
--

At 12:01 17/03/04 +0000, Simon Marlow wrote:
>
>On a related note, I recently implemented a System.Process library on
>Unix.  Source code attached.  The Windows implementation should be
>relatively straightforward.  Porting it to Hugs will require
>System.Posix.forkProcess, but I don't see any great difficulties there.
>
>One warning: if you want to use it in a concurrent environment with GHC,
>you need to use GHC's threaded RTS (i.e. use the -threaded option in the
>forthcoming GHC 6.2.1), otherwise waitForProcess will block all threads.
>
>POpen-type abstractions can easily be layered on top of the
>functionality here - indeed the library should probably contain some
>higher-level versions which correspond to common usage.
>
>I think this is a good platform-independent abstraction for process
>management.  What do others think?
>
>Cheers,
>         Simon
>
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact