defaultPoolConfig's use of capability count trips up max resources check

[dten]

Max resources must be specified when calling defaultPoolConfig but by default the stripe count is set to capability count. If someone sets max resources to for example 10, then this runs fine on a machine with 8 cores but fails with poolMaxResources must not be smaller than numStripes on a machine with 16 cores. This seems like quite an easy thing to trip over for the defaults.

[arybczak]

Do you have any proposition for a solution?

[dten]

Perhaps if the stripe count is Nothing it becomes the minimum of the number of capabilities and the max resources.
Edit: I initially wrote maximum but that's wrong lol

[fumieval]

I think #16 is a promising countermeasure

[thomasjm]

+1, this issue makes the library much more hazardous to use. Would love to see something like #16 merged.

[chreekat]

I just got an unexpected runtime error trying to upgrade because of the related change in behavior.

I honestly have no idea what values I should be supplying now. Am I supposed to know in advance how many cores my app will be run with? Or should I artificially restrict the number of stripes...?

Ah, I see in #33 that I guess I should be using GHC.Conc.numCapabilities. Ok.

Note that #33 was incomplete. There's still a second paragraph that is in error.