More forking trouble on Windows
This is a GHC tracking issue for Cabal #7309 as the issue has implications beyond Cabal and
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, !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.,
use_process_jobs = True and
hsc2hs then tries to start
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.