More forking trouble on Windows
This is a GHC tracking issue for Cabal #7309 as the issue has implications beyond Cabal and hsc2hs
.
In #9775 (closed) we found that Windows lack of support for fork
was resulting in failed builds due to GHC failing to wait until subprocesses have finished execution (since we waited on the parent, not its forked children) (see process#70).
To fix this we introduced (in process#80) the use_process_jobs
field into process
, which creates and assigned the created process to a job object. The idea is that processes created by the subprocess will inherit the job assignment and waitProcess
can wait on the job instead of the process itself. In this way, the theory went, we can robustly wait on an entire tree of processes.
Making this feature robust was a long road (see process#167, process#196, #17926 (closed), #18274 (closed)) and required a fair number of changes in GHC and core libraries (see Cabal#6529, hsc2hs#29, and !1405 (closed), !2772 (merged)).
Now it seems that this approach isn't quite sufficient on some versions of Windows (namely Windows 7 and earlier). See Cabal#7309. In short, the problem is due to this documented behavior of AssignProcessToJobObject
on Windows 7 and earlier:
A process can be associated only with a single job. [...] If a process is associated with a job, all child processes it creates are associated with that job by default.
This breaks our use case, where, e.g., Cabal
starts hsc2hs
with use_process_jobs = True
and hsc2hs
then tries to start gcc
with use_process_jobs = True
. The second call will fail with ERROR_ACCESS_DENIED
on Windows 7 and earlier.
All of this is fine with later versions of Windows due to the introduction of nested jobs.