[Bodigrim]

Mitigates #478.

@arybczak could you give it a try please?

[arybczak]

Thanks. It has some holes, I've put an improved version in #483.

[Bodigrim]

I've rebased and updated the branch to account for --RTS and GHCRTS, thanks for catching it! And so sorry for being late with the response.

Looking at #483, it seems you took a different approach to the problem?.. It seems you are not picking x from -Nx but rather just check whether it is -N1 or not. Could you perhaps rebase atop of my branch so that we can clearly see the difference?

How does #483 account for --with-rtsopts though?

[Bodigrim]

Is there a reason we cannot use fromIntegral . nCapabilities . parFlags <$> getRTSFlags? I tried it, but it seems to interact wrongly with --with-rtsopts, but it is gettting late and maybe I just misunderstand it.

[arybczak]

Could you perhaps rebase atop of my branch so that we can clearly see the difference?

There's little point. It's an alternative solution that changes all the places this PR changes, so it would essentially be a revert of this PR and then application of my changes.

Looking at #483, it seems you took a different approach to the problem?

Yes, because your approach ignores the value of getNumCapabilities. If a user sets up their own number of capabilities, IMO it's a conscious choice that should be respected.

Mine starts with this idea - if the result of getNumCapabilities is >1, then there's nothing to do. Otherwise it checks if 1 capability was explicitly requested by RTS options in the command line or GHCRTS env var, because if getNumCapabilities returns 1, it's not clear whether it was requested to be 1 by RTS flags or not set at all.

How does #483 account for --with-rtsopts though?

By checking the result of getNumCapabilities. This handles every -with-rtsopts="-Nx" and -with-rtsopts="-maxNx" for x > 1. Sadly, -with-rtsopts="-N1" and -with-rtsopts="-maxN1" can't be detected by GHC's public API.

Here's a pretty table showing what my PR handles vs yours, if you don't specify -jX at command line for tasty.

DEFAULT is the number of cores, i.e. the result of getNumProcessors. Bold is a wrong answer.

Setup	expected thread count	#483	#482
no RTS options	DEFAULT	DEFAULT	DEFAULT
+RTS -N	DEFAULT	DEFAULT	DEFAULT
+RTS -N2	2	2	2
+RTS -N1	1	1	1
+RTS -maxN2	2	2	DEFAULT
+RTS -maxN1	1	1	DEFAULT
GHCRTS=-N	DEFAULT	DEFAULT	DEFAULT
GHCRTS=-N2	2	2	2
GHCRTS=-N1	1	1	1
GHCRTS=-maxN2	2	2	DEFAULT
GHCRTS=-maxN1	1	1	DEFAULT
-with-rtsopts=-N4	4	4	DEFAULT
-with-rtsopts=-maxN4	4	4	DEFAULT
-with-rtsopts=-N1	1	DEFAULT	DEFAULT
-with-rtsopts=-maxN1	1	DEFAULT	DEFAULT
setNumCapabilities 4 before parsing	4	4	DEFAULT
+RTS -N4, then setNumCapabilities 1 before parsing	1	1	4
setNumCapabilities 1 before parsing, no RTS options	1	DEFAULT	DEFAULT
non-threaded RTS	1	1	1

[arybczak]

Is there a reason we cannot use fromIntegral . nCapabilities . parFlags <$> getRTSFlags? I tried it, but it seems to interact wrongly with --with-rtsopts, but it is gettting late and maybe I just misunderstand it.

I used it in 97963ec to plug a small hole.

I'm not sure what interaction you're talking about, seems to work fine here.

[Bodigrim]

Closing as superseded by #485.