#3994: Add support for creating and interrupting process groups
----------------------------------+-----------------------------------------
Reporter: hamish | Owner: simonmar
Type: feature request | Status: patch
Priority: high | Milestone: 7.2.1
Component: libraries/process | Version: 6.12.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------+-----------------------------------------
Comment(by Favonia):
Recently I have implemented similar functionality for my own project.
While I am more than glad to see people discussing about this, I have some
observations/ideas different from the current patch.
* I suggest another name '''interruptProcessGroupOf''' to clearly
distinguish process groups from processes. Actually, the proposed patch
might fail if the child changed its process group. A more reliable
solution for {{{POSIX}}} might look up the current process group first.
(See the following points for the problem of my approach with the current
library.) There should be some ways to find out the root process in
Windows? (Sorry that I do not program in Windows.) If this is indeed
possible, then we can interrupt a group even if it is not created with the
new flag.
* Also I prefer '''create_group''' over '''new_group''' for consistency
with ({{{createProcessGroup}}}). This is just a personal opinion, though.
* (A little off-topic:) For checking the process group in {{{POSIX}}}, I
recommend re-implementing {{{System.Posix.Process.getProcessGroup}}} by
the more standardized {{{getpgid}}} instead of {{{getpgrp}}}. The
standardized version make it possible to query the process group of a
process, and is more consistent with {{{setProcessGroup}}}. (This is not
entirely the library's fault. {{{BSD}}}/{{{System V}}}/{{{POSIX}}} have
different sets of APIs. In my opinion we should have a full set of
{{{POSIX}}} API:
{{{
getProcessGroupIDOf :: ProcessID -> IO ProcessGroupID
setProcessGroupIDOf :: ProcessID -> ProcessGroupID -> IO ()
joinProcessGroupID :: ProcessGroupID -> IO () -- a special case
recruitProcessID :: ProcessID -> IO () -- another special case
getCurrentProcessGroupID :: IO ProcessGroupID -- maybe a shorter name?
setCurrentProcessGroupID :: ProcessID -> IO ()
}}}
* Perhaps we need to take care of the situation that we are interrupting
ourself. Maybe we should temporarily block the signals while playing
around processes, at least on {{{POSIX}}}.
* I am not sure if adding the suffix {{{2}}} is a good idea. Certainly in
some cases this is unavoidable, but ideally we should only rely on the
version number. Personally I feel the high-level process handling library
is far from complete, and we might need suffixes 3,4,... in the future.
* I can see the patch is using something like {{{Data.Bits}}} to handle
{{{close_fds}}} and the new flag. I think this is a good move, as it seems
efficient, ready for more flags, and unrelated to the interface. (Please
correct me if I am wrong.) However, defining the constants in the header
might make the program more clearer. Especially this part:
{{{
((if mb_close_fds then 1 else 0).|.(if mb_new_group then 2 else 0))
}}}
* Also I am not convinced that we should use {{{ProcessInfo}}} to hold
process ID. MSDN says the process ID can always be retrieved by using
system call {{{GetProcessId}}}. The old handler should work. I am trying
to minimize the changes we need to implement the functionality.
* Another somewhat-related interesting idea is to implement
'''suspension'''. This is more complicated, though. I think a more useful
usage is to have {{{suspendProcessGroupOf}}} and
{{{continueProcessGroupOf}}}. This should be trivial for {{{POSIX}}}
systems by using {{{SIGTSTP}}} and {{{SIGCONT}}}. As for Windows, from
MSDN documents I have learned that we can find out all attached processes
in a console progress group, and then suspend threads in the processes.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3994#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
