Duncan Coutts pushed to branch wip/dcoutts/capability-yield at Glasgow Haskell Compiler / GHC Commits: 0f64f348 by Cheng Shao at 2026-07-16T15:41:08+00:00 ci: add missing docker permission workaround in abi-test job - - - - - 660cb239 by Cheng Shao at 2026-07-16T19:37:48+00:00 bindist: Fix make install -j race condition on macos/freebsd This patch fixes make install -j race condition on macos/freebsd. BSD install fails with EEXIST when multiple install processes concurrently create the same prefix directory. So we add an `install_dirs` prerequisite job that sequentially creates the directories for subsequent jobs to work with. Fixes #27499. Co-authored-by: Codex <codex@openai.com> - - - - - 08130257 by Cheng Shao at 2026-07-16T19:37:48+00:00 ci: run bindist make install with -j This patch makes the ci scripts run `make install` with `-j` to reduce wall clock time when installing the bindist, see related issue for benchmark numbers. This only affects ghc ci logic, the user-facing default is up to distributors and is still `-j1`. Closes #27029. - - - - - d5ae6906 by Adam Gundry at 2026-07-17T04:57:43-04:00 Mark various language extension flags as deprecated (see #27329) The following language extensions are now deprecated: - AlternativeLayoutRule - AlternativeLayoutRuleTransitional - ParallelArrays - PolymorphicComponents - Rank2Types In addition, the warning `-Walternative-layout-rule-transitional` has been marked as deprecated, as it is emitted only under the deprecated extension `XAlternativeLayoutRuleTransitional`. - - - - - fe3b059c by Andrew Lelechenko at 2026-07-17T04:58:26-04:00 base: re-export GHC.Environment.getFullArgs from System.Environment CLC proposal https://github.com/haskell/core-libraries-committee/issues/431 - - - - - f46cc936 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Minor doc & comment improvements to releaseCapability_ - - - - - bea022e6 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Remove redundant USED_IF_THREADS attribute on Capability utilities - - - - - 71d4315e by Duncan Coutts at 2026-07-17T10:46:29+01:00 Move several Capability utils from Schedule.{c,h} to Capability.{c,h} They probably should have been there all along. This means all the pending_sync functionality is within Capability.{c,h}. We only expose pending_sync for the purpose of inline header functions. - - - - - 5660f38f by Duncan Coutts at 2026-07-17T10:46:29+01:00 Shuffle the pending sync type declarations for better readability Move them together into the section with the related functions that use them. Also drop the legacy use of the C 'volatile' modifier on the pending_sync variable. We use C atomics for such access, not volatile. - - - - - 553ec645 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Rename returning task queue helpers Follows a naming convention elsewhere. It also gives us suitable names to distinguish appending vs prepending to the queue, and we're about to add a prepend operation. - - - - - 3985384a by Duncan Coutts at 2026-07-17T10:46:29+01:00 Add a prepend operation for the returning task queue With a pending sync (e.g. for GC), we really want to be able to prioritise the task waiting on the sync over all other returning tasks. To do that we will need to prepend to the queue rather than append. - - - - - e3a6052d by Duncan Coutts at 2026-07-17T10:46:29+01:00 Introduce waitForCapability_ with additional priority arg Split waitForCapability into a wrapper with the existing type (since it is exported via the RTS API) and a worker with an extra argument. The new high_priority argument controls whether the task is appended or prepended to the returing task queue. The default, used by the waitForCapability wrapper, is false, meaning append to the end of the queue. This gives fairness. - - - - - 3fe6de57 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Make acquireAllCapabilities use high_priority on waitForCapability_ As discussed in issue #27473, a sync of all capabilities is something that needs to happen promptly (but often doesn't). One source of delay is that acquireAllCapabilities using waitForCapability would put the task trying to acquire each capability at the _end_ of the returning task queue. This gave every other returing task a full timeslice to run. Meanwhile, several other capabilities are blocked waiting for the sync to complete, leading to a loss of throughput. We use the new high_priority arg to waitForCapability_ to ensure that the requesting task is put on the front of the returing task queue. This will ensure that releaseCapability_ will prioritise giving the capability to the task requesting the sync. - - - - - 2d2c6fc3 by Duncan Coutts at 2026-07-17T10:46:29+01:00 In releaseCapability_ make the pending_sync case self-contained Previously the pending_sync case had to be checked _after_ the returning tasks case, since one of the possibilities (indeed the more likely possibility) is that the task calling waitForCapability will have enqueued itself as a returning task. Now we make the pending_sync case self-contained. We note in a comment the two possibilities: either the task calling waitForCapability has enqueued itself already and is waiting, or it's not got there yet. We can handle the first case by giving the capability to the task at the head of the returning tasks queue, and the second case by leaving the capability free. Another way to look at this, is that we move a special case of handling of the returning task case into the pending_sync case. That special case being a returing task during a pending sync. This makes the order of handling returning tasks vs pending sync independent. This is good, because really they're in the wrong priority order and we want to flip them around. - - - - - 546ff30f by Duncan Coutts at 2026-07-17T10:46:29+01:00 In releaseCapability_ prioritise pending sync over returning tasks Fixes issue #27460 As explained in the issue, a pending sync (e.g. for GC) should be dealt with promptly. Returning tasks are a lower priority. Historically however we had to check returning tasks first, because the synchronisation mechanism mixed up the task doing a sync with the tasks returning from safe FFI calls. The task performing the sync was very likely to be queued on the returning task list (and historically it was at the _end_ of this list!). We have now arranged that the task performing the sync is at the front of the returning task list, and in the pending sync case we now check the returning task list and run the first task from there if it there is one. This is by no means perfect, but it is better. See issue #27473 for a more general issue of cleaning up the design of the pending sync. - - - - - 0d2157a4 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Extend releaseCapability_ with an extra wakeup_worker modifier Document within releaseCapability_ the basic approach of looking for a series of conditions in priority order and acting on them. Explain the existing modifier within that understanding. Then add a new modifier, wakeup_worker and explain it in similar terms. What it does is skip two of the conditions in the priority list, with the effect that we prioritise waking up a worker task over a returning task or bound task. This feature is not yet used in this commit, but it will be used as part of a scheme to allow in-RTS I/O managers in the threaded RTS. This scheme will make use of being able to start a background worker thread, and that will use this feature to start it promptly. Also correct the yieldCapability docs to cover all the conditions, and in priority order for consistency. - - - - - 48e82bd1 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Move enqueueWorker next to where it is used. It's not general purpose at all. It's very specifically crafted to work with it's only caller: yieldCapability. It does very suprising things like releaseCapability_, release locks and terminate threads. This logic would be much clearer if done within yieldCapability. - - - - - 0c630f94 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Move code out of enqueueWorker and into releaseCapability_ Instead of directly releasing locks and terminating tasks, have it return whether the enqueue was successful or not. In the latter case, releaseCapability_ itself will release locks and terminate the task. This makes the logic of releaseCapability_ a lot clearer. Fiddling with tasks is what releaseCapability_ does, so it's better not to try and encapsulate this within a helper function. - - - - - 125e5f10 by Duncan Coutts at 2026-07-17T10:46:29+01:00 Clarify the logic and control flow in yieldCapability yieldCapability is unfortunately a bit complicated. This change restructures things slightly but should keep the behaviour the same. Previously after calling releaseCapability_ we had a bunch of alternatives, where in each branch we would use RELEASE_LOCK(cap->lock) and do various things before/after the lock is released. This was a bit hard to follow, or to extend (which we need to do). So now we have unconditional acquire and release of the cap->lock, so it's clear where that happens, with releaseCapability_ in between. Then in between these steps we have the various other pre/post actions. Some before releaseCapability_, some after while holing the lock, and some after having released the lock. We explain this structure in a longer comment, and refer back to the structure from the code. - - - - - 64 changed files: - .gitlab-ci.yml - .gitlab/ci.sh - + changelog.d/T27329 - + changelog.d/fix-make-install-j - compiler/GHC/Driver/Flags.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Tc/Types/Rank.hs - docs/users_guide/expected-undocumented-flags.txt - docs/users_guide/exts/rank_polymorphism.rst - docs/users_guide/exts/static_pointers.rst - hadrian/bindist/Makefile - libraries/base/changelog.md - libraries/base/src/System/Environment.hs - libraries/ghc-internal/ghc-internal.cabal.in - rts/Capability.c - rts/Capability.h - rts/Messages.c - rts/RtsAPI.c - rts/Schedule.c - rts/Schedule.h - testsuite/tests/backpack/should_compile/T13149.bkp - testsuite/tests/determinism/determ017/A.hs - testsuite/tests/ghci/scripts/T12005.script - testsuite/tests/haddock/perf/Fold.hs - testsuite/tests/indexed-types/should_fail/T7354.hs - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/layout/layout001.stdout - testsuite/tests/layout/layout002.stdout - testsuite/tests/layout/layout003.stdout - testsuite/tests/layout/layout004.stdout - testsuite/tests/layout/layout005.stdout - testsuite/tests/layout/layout006.stdout - testsuite/tests/layout/layout007.stdout - testsuite/tests/layout/layout008.stdout - testsuite/tests/layout/layout009.stdout - testsuite/tests/linear/should_compile/T1735Min.hs - + testsuite/tests/parser/should_compile/T13087.stderr - testsuite/tests/parser/should_fail/T8431.stderr - testsuite/tests/parser/should_fail/readFail038.stderr - testsuite/tests/perf/compiler/T3064.hs - testsuite/tests/polykinds/T7594.hs - testsuite/tests/programs/thurston-modular-arith/Main.hs - testsuite/tests/rts/ipe/IpeStats/Fold.hs - testsuite/tests/simplCore/should_compile/T11562.hs - testsuite/tests/simplCore/should_run/T3591.hs - testsuite/tests/typecheck/should_compile/DeepSubsumption02.hs - testsuite/tests/typecheck/should_compile/T12507.hs - testsuite/tests/typecheck/should_compile/T13951.hs - testsuite/tests/typecheck/should_compile/T18920.hs - testsuite/tests/typecheck/should_compile/T2595.hs - testsuite/tests/typecheck/should_compile/T7541.hs - testsuite/tests/typecheck/should_fail/T6069.stderr - testsuite/tests/typecheck/should_fail/T7368a.hs - testsuite/tests/typecheck/should_run/T1735_Help/Basics.hs - testsuite/tests/typecheck/should_run/T3731-short.hs - testsuite/tests/typecheck/should_run/T3731.hs - testsuite/tests/typecheck/should_run/church.hs - testsuite/tests/typecheck/should_run/tcrun008.hs - testsuite/tests/typecheck/should_run/tcrun017.hs - testsuite/tests/typecheck/should_run/tcrun026.hs - testsuite/tests/typecheck/should_run/tcrun035.hs - testsuite/tests/typecheck/should_run/tcrun036.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f92cb93118b92a61fe7be82bd14cb98... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f92cb93118b92a61fe7be82bd14cb98... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help