Patch to add process group support

[Simon Marlow]

For future reference, the procedure for changes like this is to follow 
the Library Submissions guidelines at 
http://www.haskell.org/haskellwiki/Library_submissions.

In this case you've already made a patch and a detailed proposal, so I 
don't see any reason why we shouldn't consider it anyway.

My thoughts on the changes:

  - yes to adding new_group to the CreateProcess record, and
    corresponding support to System.Process.Internals

  - no to adding runCommandNewGroup, and the other *NewGroup
    functions.  These were kept mostly for backwards compatibility
    anyway, the new API is createProcess, shell, proc, readProcess.
    I don't think people need new_group often enough to provide
    canned variants of runCommand etc. for it.

Cheers,
	Simon

On 17/04/2010 16:26, Hamish Mackenzie wrote:
> The attached patch for the process package adds support for creating and interrupting process groups on Unix and Win32 systems.  Currently we have to use a nasty hack in Leksah that only works on Unix systems (and even then not very well).  On Win32 Leksah's background build feature is dreadful as a results (because it has no way to interrupt the build and start over when the user makes more changes).
>
> I would love to get this onto Hackage somehow, if not as a new version of the process package, perhaps as an alternative package ("process-groups" using System.Process.Groups instead of System.Process).
>
> Please can you have a look and let me know what you think?
>
> Thanks,
> Hamish
>
>
> This patch introduces the following functions to System.Process
>
> * runCommandNewGroup, runProcessNewGroup, runInteractiveCommandNewGroup and runInteractiveProcessNewGroup __
> These are variations on the existing functions for running processes.  They create the child process as the lead process in a new process group.
> Unix - calls setpgid in both the parent and the child process after fork.
> Win32 - calls CreateProcess with the CREATE_NEW_PROCESS_GROUP set.  I also had it unset CREATE_NO_WINDOW because this seems to prevent the child attaching to the parents console (and therefor stops interuptProcessGroup from working).
>
> * interruptProcessGroup
> This function can be used interrupt a running process group.
> Unix - calls signalProcessGroup to send sigINT
> Win32 - If the process ID is known it calls generateConsoleCtrlEvent to send cTRL_BREAK_EVENT
>
>
> __ Compatibility __
>
> Backward Compatibility
> CreateProcess has a new field new_group which may need to be added to some existing code. If set to False the current behaviour is preserved. As far as I know this is the only change that could break existing code.
>
> Linker Errors
> I have renamed the C functions it used in order to prevent linker errors when using this new version with the existing process package.
>
>
> __ Win32 Only __
>
> On Win32 the process handle is not the same as the process ID and there is no reliable way to convert from one to the other.  I have added an interface that allows access to the process ID, but does not change the behaviour of the existing functions.
>
> * PINFO
> Replaces PHANDLE in the ProcessHandle type.
>      type PINFO = (PHANDLE, Maybe Word32) -- Handle and Process ID
>
> * mkProcessHandleWithPID
> Like mkProcessHandle but allows you to specify the processes ID as well.  This function is now used in all the run functions so the ProcessHandle they return will contain a process ID.
>
> * withProcessInfo and withProcessInfo_
> Like withProcessHandle functions but gives you access to the PINFO (not just the PHANDLE it contains).
>