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).