Patch to add process group support
marlowsd at gmail.com
Mon Apr 19 08:57:23 EDT 2010
For future reference, the procedure for changes like this is to follow
the Library Submissions guidelines at
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.
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?
> 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).
More information about the Libraries