Update semaphore-compat to 2.0.0.0 to fix #9993 - #11628

wz1000 · 2026-03-17T11:11:56Z

Patches conform to the coding conventions.
Any changes that could be relevant to users have been recorded in the changelog.
- Is the change significant? If so, remember to add significance: significant in the changelog file.
The documentation has been updated, if necessary.
Manual QA notes have been included.
Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

Update to semaphore-compat 2.0.0 fixing #9993 and https://gitlab.haskell.org/ghc/ghc/-/issues/25087

semaphore-compat now uses a unix sockets based implementation.

Semaphore identifiers are now versioned, and we can really on the versioning
scheme to detect semaphore version mismatch with GHC and fallback gracefully if
possible.

GHC patch: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15729

After the GHC patch lands, it will include a "Semaphore version" field in its
settings file/--info output that we can use to guide Cabal behaviour.

If this field does not exist (and ghc is 9.8+), then we assume it uses version v1 of the protocol
and this triggers a graceful degradation of behaviour to -jN without semaphore based coordination.

See also

semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8
ghc-proposals change: ghc-proposals/ghc-proposals#673

Mikolaj · 2026-04-09T17:59:37Z

Is this needed for GHC 10 and so for Cabal 3.18? If so, how can we get this merged now?

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253

sheaf

Yes, this looks good.

Personally I would like to avoid the "normal parallelism control" phrasing (that predates this PR) as I think we can be more specific about what we are falling back to, but that's just a nitpick.

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253

philderbeast · 2026-05-19T15:48:01Z

Could we move forward on this? I recently did a cabal install cabal-install:exe:cabal --overwrite-policy=always from the master branch (in the past week or two) to check behaviour between the master branch and some other branch (can't remember which) and I'm hitting the #9993 issue often. I'm using the following as a build check:

$ cabal build all --enable-tests --enable-benchmarks -j --semaphore --ghc-options="-Werror"

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253

wz1000 · 2026-05-21T13:29:42Z

https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 has been merged, which took longer than expected. I will try to merge the GHC MR tomorrow, and then this should be unblocked for merging.

sheaf · 2026-05-21T13:41:44Z

Could we move forward on this? I recently did a cabal install cabal-install:exe:cabal --overwrite-policy=always from the master branch (in the past week or two) to check behaviour between the master branch and some other branch (can't remember which) and I'm hitting the #9993 issue often.

@philderbeast I don't think that's related. In this PR we are fixing the situation in which GHC and Cabal were linked against different C standard libraries which have incompatible implementations of POSIX semaphores.

If you are running into another issue and are able to provide a reproducer, please open a ticket and I will investigate it.

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253 (cherry picked from commit 8db331a)

Mikolaj · 2026-05-27T16:50:55Z

@wz1000: apparently, before this got merged, a conflict emerged, so it has to be resolved before mergify can proceed (but this time without waiting, which we can force if needed).

…ab.haskell.org/ghc/ghc/-/issues/25087 Also update index-state and bootstrap plans to pull in new version of semaphore-compat. semaphore-compat now uses a unix sockets based implementation. Semaphore identifiers are now versioned, and we can really on the versioning scheme to detect semaphore version mismatch with GHC and fallback gracefully if possible. GHC patch: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15729 After the GHC patch lands, it will include a "Semaphore version" field in its settings file/`--info` output that we can use to guide Cabal behaviour. If this field does not exist (and ghc is 9.8+), then we assume it uses version v1 of the protocol and this triggers a graceful degradation of behaviour to `-jN` without semaphore based coordination. See also semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 ghc-proposals change: ghc-proposals/ghc-proposals#673

wz1000 · 2026-05-27T16:57:28Z

@wz1000: apparently, before this got merged, a conflict emerged, so it has to be resolved before mergify can proceed (but this time without waiting, which we can force if needed).

resolved.

mergify · 2026-05-27T18:41:52Z

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253 (cherry picked from commit 8db331a)

This reverts commit dd941a5, reversing changes made to 937b961.

On Linux and other POSIX platforms, GHC's -jsem jobserver client now speaks v2 of the semaphore-compat protocol, which uses Unix domain sockets in place of POSIX named semaphores. This avoids the libc-ABI issues that affected the old implementation. Windows is unaffected and continues to use the v1 protocol (Win32 named semaphores); its reported protocol version remains v1. When GHC receives a -jsem name whose protocol version it does not support, it emits a -Wsemaphore-version-mismatch warning and falls back to -j<N> rather than crashing. ghc --info exposes the supported version in a new "Semaphore version" entry so cabal-install can detect a mismatch before invoking GHC. Users on a cabal-install that predates the v2 update will continue to build successfully on Linux/POSIX, but will lose the cross-process -jsem coordination and fall back to -j<N> per GHC invocation. Users must upgrade to a cabal-install that supports protocol v2 to recover full parallelism. Also fix a leak in cleanupSem (#27253): cleanupSem used to snapshot heldTokens and release them before killing the loop, while the loop's in-flight acquire/release children could still be mutating it. Cleanup now runs inside the loop's own exit handler, after draining the active child via a new activeChild TVar, so the snapshot has no concurrent mutator. See also: - GHC proposal amendment: ghc-proposals/ghc-proposals#673 - cabal-install patch: haskell/cabal#11628 - semaphore-compat MR: https://gitlab.haskell.org/ghc/semaphore-compat/-/merge_requests/8 Bump semaphore-compat submodule to 2.0.0 Fixes #25087 and #27253 (cherry picked from commit 8db331a)

wz1000 mentioned this pull request Mar 17, 2026

Update jsem proposal to address problems discovered in GHC #25087 (under review) ghc-proposals/ghc-proposals#673

Merged

geekosaur previously requested changes Mar 17, 2026

View reviewed changes

Comment thread cabal.project Outdated

wz1000 force-pushed the wip/semaphore-v2 branch 3 times, most recently from 67769ee to 98685dd Compare March 19, 2026 04:30

Bodigrim approved these changes Mar 19, 2026

View reviewed changes

Comment thread changelog.d/semaphore-version-compat.md Outdated

Comment thread Cabal/src/Distribution/Simple/Compiler.hs Outdated

sheaf reviewed Mar 20, 2026

View reviewed changes

Comment thread cabal-install/src/Distribution/Client/JobControl.hs Outdated

Comment thread cabal-install/src/Distribution/Client/JobControl.hs Outdated

Comment thread changelog.d/semaphore-version-compat.md Outdated

wz1000 force-pushed the wip/semaphore-v2 branch 4 times, most recently from cea0774 to 2758155 Compare May 12, 2026 11:55

wz1000 force-pushed the wip/semaphore-v2 branch from 2758155 to 067e12c Compare May 13, 2026 13:01

wz1000 force-pushed the wip/semaphore-v2 branch 2 times, most recently from d49fb8c to ee96ef5 Compare May 19, 2026 09:05

sheaf approved these changes May 19, 2026

View reviewed changes

wz1000 force-pushed the wip/semaphore-v2 branch 2 times, most recently from d564a18 to 1e9c8ae Compare May 21, 2026 13:27

wz1000 force-pushed the wip/semaphore-v2 branch from 1e9c8ae to b8817fb Compare May 21, 2026 14:00

sheaf approved these changes May 25, 2026

View reviewed changes

Mikolaj added the merge me Tell Mergify Bot to merge label May 25, 2026

mergify Bot added the ready and waiting Mergify is waiting out the cooldown period label May 25, 2026

mergify Bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label May 27, 2026

wz1000 force-pushed the wip/semaphore-v2 branch from 96ccd50 to 2cac53b Compare May 27, 2026 16:57

mergify Bot added the queued label May 27, 2026

mergify Bot merged commit dd941a5 into haskell:master May 27, 2026
63 checks passed

mergify Bot removed the queued label May 27, 2026

Bodigrim mentioned this pull request Jun 1, 2026

Reduce number of x86_64-linux bindists to 1 #11926

Closed

MangoIV mentioned this pull request Jun 7, 2026

semaphore-compat-2.0 commercialhaskell/stackage#8032

Open

1 task

juhp mentioned this pull request Jun 7, 2026

backport semaphore-compat-0.2 support to 3.14 and 3.16 #11946

Open

TeofilC added a commit that referenced this pull request Jun 10, 2026

Revert "Merge pull request #11628 from wz1000/wip/semaphore-v2"

8d4b3d3

This reverts commit dd941a5, reversing changes made to 937b961.

MangoIV mentioned this pull request Jun 14, 2026

haskellPackages: stackage LTS 24.38 -> Nightly 2026-09-01; ghc: 9.10.3 -> 9.12.5-rc3 NixOS/nixpkgs#521260

Draft

sternenseemann mentioned this pull request Jun 23, 2026

Support semaphore-compat 2.0.0 commercialhaskell/stack#6934

Open

ffaf1 mentioned this pull request Sep 1, 2026

cabal 3.18.1.0 effectively dropped semaphore support #12306

Open

Navigation Menu

Uh oh!

Update semaphore-compat to 2.0.0.0 to fix #9993 - #11628