Win32 process spawning, POpen and Hugs, revisited
GK at ninebynine.org
Wed Mar 17 15:01:34 EST 2004
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
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
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?
>Libraries mailing list
>Libraries at haskell.org
More information about the Libraries