Update semaphore-compat to 2.0.0.0 to fix #9993 by wz1000 · Pull Request #11628 · haskell/cabal

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

geekosaur · 2026-03-17T20:44:43Z

 package Cabal
  flags: +git-rev
+
+source-repository-package


This needs to be added to the other project files as well, or perhaps imported from project-cabal/ghc-options.config or one of the other imports. In particular, cabal.validate.project will need it for CI.

We may also need a warning somewhere that HEAD relies on an unreleased package when this goes in.

I don't know if we have a common place to put source-repository-package yet. Maybe create and import a new file, project-cabal/deps-external.config¹ or project-cabal/external-pkgs.config or project-cabal/source-deps.config.

Footnotes

That's the name I went with in Updo. ↩

Is there a reason semaphore-compat-2.0 cannot be released though? It would save a lot of pain not to deal with source-repository-package here.

My assumption is that there's a bit of a dependency loop here and a cabal build using it is needed to test it fully before release. And it's relatively less painful to use source-repository-package in cabal than to make Hadrian use it.

Correction: for ghc it's just a pinned submodule. Testing it before release still requires the cabal equivalent (source-repository-package) on our side.

The source-repository-package is temporary, I will drop it once we release semaphore-compat 2.0. I intend to do this before this PR is merged.

Bodigrim · 2026-03-19T20:43:01Z

+synopsis: Detect semaphore version mismatch between cabal-install and GHC
+packages: [Cabal, cabal-install]
+prs: 0000
+issues: 0000


prs and issues should be updated before merge.

Bodigrim · 2026-03-19T20:44:04Z

+jsemVersion :: Compiler -> Maybe Int
+jsemVersion comp = case compilerFlavor comp of
+  GHC -> case Map.lookup "Semaphore version" (compilerProperties comp) of
+    Just verStr | [(v, "")] <- reads verStr -> Just v


I'd prefer Just v <- maybeRead verStr, I think it is easier to read than [(v, ""] <- reads verStr, but up to you.

sheaf · 2026-03-20T09:29:30Z

+    Left err -> do
+      warn verbosity $
+        "Failed to create semaphore: " ++ show err
+          ++ "; falling back to normal parallelism control."


Can we say falling back to -jN (with N the actual parallelism limit)? "Normal parallelism control" is needlessly confusing IMO.

sheaf · 2026-03-20T09:31:39Z

+-- If the compiler doesn't report a "Semaphore version" field (GHC 9.8–9.14),
+-- we assume v1. On POSIX, v1 and v2 are incompatible (different mechanisms).
+-- On Windows, all versions are compatible (same Win32 API).


Better not say this in this comment IMO. The source of truth is versionsAreCompatible, so just point to that instead. Otherwise this comments risks becoming wrong without anyone noticing.

sheaf · 2026-03-20T09:34:52Z

+significance: significant
+---
+
+When using `--semaphore`, cabal-install now checks whether the selected GHC's


I think this needs to point out that the whole reason for this change is that v2 of semaphore-compat does not suffer from the issue v1 had with ghc and cabal being linked against different C standard libraies.

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

…ab.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

…ompat 2.0.0

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 requested changes Mar 17, 2026

View reviewed changes

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

sheaf reviewed Mar 20, 2026

View reviewed changes

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

wz1000 added 2 commits May 13, 2026 18:31

DROP me before merging: use source-repository-package for semaphore-c…

067e12c

…ompat 2.0.0

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

Update semaphore-compat to 2.0.0.0 to fix #9993#11628
wz1000 wants to merge 2 commits into
haskell:masterfrom
wz1000:wip/semaphore-v2

wz1000 commented Mar 17, 2026

Uh oh!

geekosaur Mar 17, 2026

Uh oh!

philderbeast Mar 17, 2026 •

edited

Loading

Uh oh!

Bodigrim Mar 18, 2026

Uh oh!

geekosaur Mar 18, 2026

Uh oh!

geekosaur Mar 18, 2026

Uh oh!

wz1000 Mar 18, 2026 •

edited

Loading

Uh oh!

Bodigrim Mar 19, 2026

Uh oh!

Bodigrim Mar 19, 2026

Uh oh!

sheaf Mar 20, 2026

Uh oh!

sheaf Mar 20, 2026

Uh oh!

sheaf Mar 20, 2026

Uh oh!

Mikolaj commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

wz1000 commented Mar 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

philderbeast Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wz1000 Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikolaj commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

philderbeast Mar 17, 2026 •

edited

Loading

wz1000 Mar 18, 2026 •

edited

Loading