Update semaphore-compat to 2.0.0.0 to fix #9993#11628
Update semaphore-compat to 2.0.0.0 to fix #9993#11628wz1000 wants to merge 2 commits intohaskell:masterfrom
Conversation
cabal.project
Outdated
| package Cabal | ||
| flags: +git-rev | ||
|
|
||
| source-repository-package |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Correction: for ghc it's just a pinned submodule. Testing it before release still requires the cabal equivalent (source-repository-package) on our side.
There was a problem hiding this comment.
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.
…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
wz1000
force-pushed
the
wip/semaphore-v2
branch
2 times, most recently
from
c3c4cb6 to
67769ee
Compare
wz1000
force-pushed
the
wip/semaphore-v2
branch
from
67769ee to
98685dd
Compare
| synopsis: Detect semaphore version mismatch between cabal-install and GHC | ||
| packages: [Cabal, cabal-install] | ||
| prs: 0000 | ||
| issues: 0000 |
There was a problem hiding this comment.
prs and issues should be updated before merge.
| 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 |
There was a problem hiding this comment.
I'd prefer Just v <- maybeRead verStr, I think it is easier to read than [(v, ""] <- reads verStr, but up to you.
| Left err -> do | ||
| warn verbosity $ | ||
| "Failed to create semaphore: " ++ show err | ||
| ++ "; falling back to normal parallelism control." |
There was a problem hiding this comment.
Can we say falling back to -jN (with N the actual parallelism limit)? "Normal parallelism control" is needlessly confusing IMO.
| -- 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). |
There was a problem hiding this comment.
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.
| significance: significant | ||
| --- | ||
|
|
||
| When using `--semaphore`, cabal-install now checks whether the selected GHC's |
There was a problem hiding this comment.
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.
5 participants
significance: significantin the changelog file.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/
--infooutput 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
-jNwithout 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