GHC: Ticket Query The Glasgow Haskell Compiler en-US GHC Trac 1.0.1 #3994: Add support for creating and interrupting process groups Mon, 19 Apr 2010 15:59:08 GMT hamish <p> This patch introduces the following to System.Process </p> <p> <strong>new_group</strong> </p> <p> This Bool field is added to <a class="missing wiki">CreateProcess?</a>. If it is set to True the child process will be created as the lead process in a new process group. </p> <ul><li>Unix - calls setpgid in both the parent and the child process after fork. </li><li>Win32 - calls <a class="missing wiki">CreateProcess?</a> 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). </li></ul><p> <strong>interruptProcessGroup</strong> </p> <p> This function can be used interrupt a running process group. </p> <ul><li>Unix - calls signalProcessGroup to send sigINT </li><li>Win32 - If the process ID is known it calls generateConsoleCtrlEvent to send cTRL_BREAK_EVENT </li></ul><h2 id="Compatibility"><span class="underline">Compatibility</span></h2> <p> <span class="underline">Backward Compatibility</span> </p> <p> <a class="missing wiki">CreateProcess?</a> 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. </p> <p> <span class="underline">Linker Errors</span> </p> <p> I have renamed the C functions it used in order to prevent linker errors when using this new version with the existing process package. </p> <h2 id="Win32Only"><span class="underline">Win32 Only</span></h2> <p> 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. </p> <p> <strong>PINFO</strong> </p> <p> Replaces PHANDLE in the <a class="missing wiki">ProcessHandle?</a> type. </p> <blockquote> <p> type PINFO = (PHANDLE, Maybe Word32) -- Handle and Process ID </p> </blockquote> <p> <strong>mkProcessHandleWithPID</strong> </p> <p> Like mkProcessHandle but allows you to specify the processes ID as well. This function is now used in the run* functions and createProcess, so the <a class="missing wiki">ProcessHandle?</a> they return will contain a process ID. </p> <p> <strong>withProcessInfo and withProcessInfo_</strong> </p> <p> Like withProcessHandle functions but gives you access to the PINFO (not just the PHANDLE it contains). </p> Results #5058: getProcessExitCode doesn't retry on EINTR Mon, 28 Mar 2011 18:02:25 GMT sclv <p> Just like the ticket says. The source uses throwErrnoIfMinus1, and I can't think why it shouldn't just use throwErrnoIfMinus1Retry. I think that this is an issue with a few other functions that should do the same thing, including waitForProcess and probably terminateProcess as well. </p> <p> I also wonder if the same issue is in other core libraries, but that's beyond this ticket. </p> Results #5215: process library does not build with GHC 7.0.x Tue, 24 May 2011 21:27:17 GMT Favonia <p> The process library in the trunk does not build with GHC 7.0.x. The reason is that GHC 7.0.x does not seem to support the "interruptible" FFI calls, but the macro asserts that GHC 7 supports it. </p> <p> People on #ghc (thanks to thoughtpolice) have confirmed that GHC 7.1.x supports it. I hereby propose a patch to bump the version check from 700 to 710. </p> Results #4006: System.Process doesn't encode its arguments. Fri, 23 Apr 2010 20:13:25 GMT Khudyakov <p> System.Process doesn't encode strings while creating new processes. It truncate them instead. Here is simple test case. testUnicode should always return True but does so only for ASCII string. </p> <pre class="wiki">testUnicode :: String -&gt; IO Bool testUnicode str = ((== str) . init) `fmap` (readProcess "echo" [str] "") </pre><p> In GHCi I get following: </p> <pre class="wiki">*Main&gt; testUnicode "It works here" True *Main&gt; testUnicode "А здесь сломалось" False </pre><p> I think this bug isn't controversial like <a class="closed ticket" href="" title="bug: System.IO and System.Directory functions not Unicode-aware under Unix (closed: fixed)">#3307</a> and <a class="closed ticket" href="" title="bug: getArgs should return Unicode on Unix (closed: fixed)">#3309</a> since there is no possible information loss. </p> Results