Proposal: overhaul System.Process

[Simon Marlow]

Following Duncan's suggestions below, I have a further round of changes to 
the process library for comment.   The new Haddock docs are here:

  http://darcs.haskell.org/~simonmar/process/System-Process.html

Here is the patch message:

   * More System.Process overhaul

   New functions:

     callProcess :: FilePath -> [String] -> IO ()
     callCommand :: String -> IO ()

     spawnProcess :: FilePath -> [String] -> IO ProcessHandle
     spawnCommand :: String -> IO ProcessHandle

   Changes:

     - system and rawSystem have been removed from System.Process again.
       (they were only there temporarily after the last round of changes,
       now callCommand and callProcess replace them respectively).

   On Unix systems we now use SIGCHLD to detect process completion
   instead of calling waitpid().  This has several advantages:

     - much cheaper: no extra OS threads to do the waiting
     - doesn't require -threaded to get non-blocking waitForProcess
     - waitForProcess can be interrupted
     - no zombies left around (only relevant on Unix)

   However, it relies on the new signal API (see separate proposal).  And
   these advantages aren't available on Windows (yet).

Cheers,
	Simon


Duncan Coutts wrote:
> On Thu, 2008-05-15 at 10:45 +0100, Simon Marlow wrote:
>> The latest version of the Process overhaul is here:
>>
>>   http://darcs.haskell.org/~simonmar/process/System-Process.html
> 
> 
> We discussed some ideas on #ghc today and I'm posting them here so
> people can comment.
> 
> 
>  Deprecate:
>       * runCommand
>       * runProcess
>       * runInteractiveCommand
>       * runInteractiveCommand
> 
> The rationale is that these are all more limited than the new
> createProcess and yet none of them are really convenient. It's better to
> have fewer variations if they can all be expressed easily using
> createProcess. It makes the API much simpler.
> 
> Also we'd not add `system` or `rawSystem` to `System.Process` and
> instead add new equivalents with more consistent names.
> 
> That would leave just:
> 
>       * createProcess
>       * readProcess
>       * readProcessWithExitCode
> 
> Then add the following:
> 
>       * callProcess :: FilePath -> [String] -> IO ()
>       * callCommand :: String -> IO ()
> 
> These would be synchronous like the current system and rawSystem. The
> difference is they would throw IOErrors on failure rather than returning
> the ExitCode which is so easily ignored.
> 
> These are of course only convenience functions. If someone wants the
> exit code it should be easy to do it via createProcess and
> waitForProcess. We need to make sure that is indeed the case.
> 
> We'd also add async versions of the above:
> 
>       * spawnProcess :: FilePath -> [String] -> IO ProcessHandle
>       * spawnCommand :: String -> IO ProcessHandle
> 
> that do not wait for the process to finish and return the ProcessHandle.
> Again these should be easy instances of createProcess. The docs should
> probably say as much so it's clear how to make minor variations.
> 
> We also discussed how it should be safe to GC the ProcessHandle and not
> end up with zombie processes on unix systems. On Windows it's actually
> easy because you can close the process handle which means you don't get
> the exit status of the process. On unix we have to collect the exit
> status of every child process (actually you can ignore all of them, but
> you cannot ignore them selectively).
> 
> The point is that with a convenient spawnProcess it's tempting to ignore
> the ProcessHandle result and never bother calling waitForProcess on it.
> We do want to support that. At the moment doing that would leave zombie
> processes.
> 
> We discussed a mechanism to allow GC'ing ProcessHandles that does not
> leave zombies. It'd probably involve keeping a Map PID (MVar ExitCode)
> and embedding a MVar ExitCode in the ProcessHandle. Then when we get
> notified that a child process terminated we would store the exit status
> in the MVar. Then waitForProcess would just wait on that MVar ExitCode.
> 
> The one thing we have left that we cannot express with createProcess is
> the behaviour with respect to ^C handling. For some processes we want to
> delegate ^C handling to that child process (eg imagine calling ghci).
> For others we want to handle ^C 'normally'. For details see #2301:
> http://hackage.haskell.org/trac/ghc/ticket/2301
> 
> 
> Duncan
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries