basvandijk authored Feb 07, 2012 and Simon Marlow committed Feb 08, 2012

Fixed asynchronous exception bugs in readProcess and readProcessWithExitCode This patch fixes the following two bugs:

1) If an asynchronous exception was thrown to the thread executing
   readProcess somewhere after createProcess was executed, the standard handles
   would not be closed anymore resulting in a "handle leak" so to speak.

   This is fixed by catching exceptions in the IO processing code and
   closing the standard handles when an exception occurs.
   Additionally, I also terminate the process and wait for its termination.

2) If an asynchronous exception was thrown to the
   stdout/stderr-read-thread it did not execute the putMVar anymore
   resulting in a dead-lock when takeMVar was executed.

   This is fixed by properly catching exception in the read-thread
   and propagating them to the parent thread which will then handle
   them as described above.

Fixes #5449: The process package wouldn't build outside of a GHC tree.

Win32 fixes : process.cabal and test 3994 (win32 process must be started before it can be interrupted)

As suggested by Duncan Coutts: we haven't actually changed the API,
just added to it.

       
 - fix #1780: pipes created by runInteractiveProcess are set
   close-on-exec by default
 
 - add a new, more general, form of process creation: createProcess
   Each of stdin, stdout and stderr may individually be taken
   from existing Handles or attached to new pipes.  Also it
   has a nicer API (as discussed on libraries@haskell.org).
 
 - add readProcess / readProcessWithExitCode, originally from Don
   Stewart's newpopen package.  These functions behave like C's
   popen().

 - Move System.Cmd.{system,rawSystem} into System.Process.  Later
   we can depecate System.Cmd.
 
 - Don't use O_NONBLOCK for pipes, as it can confuse the process
   attached to the pipe (requires a fix to GHC.Handle in the base
   package).

 - Provide a way to close all the file descriptors in the new
   process (see #1415)

 - add a couple more tests for the new features

 - bump the version to 2.0

Again, use os(windows) rather than os(mingw32)

It's conditionaly building/exposing the System.Process module, only with ghc.
It was being done previously in Setup.hs with an egregious hack.
Conditionally exposing modules is pretty unpleasent, but at least it's now
clear that's what it is doing.

This makes the deps work out for the System.Posix.Signals move.