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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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