In the course of solving #351, we discovered some inappropriate RNG behavior: RNGs were clone when we spawn separate threads, but cloning doesn't reseed RNGs, so there are places with potentially matching randomness streams.
As a partial solution in #368 we reset the way that we pass around RNGs on the customer side. Instead of using one and passing it by value (and occasionally cloning it), we now just create the RNG at the top of a commend when we need it. This has the drawback of potentially creating too many RNGs (especially in a close flow), which could lead to them being seeded without enough entropy.
A proper solution to this problem should do the following
Return to the convention of "create an RNG once and use it everywhere"
Use a reseedable RNG with the convention of reseeding on clone.
Decide whether it's best to pass mutable references to RNGs to each Command or give ownership (and require cloning).
Apply these changes to both customer and merchant commands.
In the course of solving #351, we discovered some inappropriate RNG behavior: RNGs were clone when we spawn separate threads, but cloning doesn't reseed RNGs, so there are places with potentially matching randomness streams.
As a partial solution in #368 we reset the way that we pass around RNGs on the customer side. Instead of using one and passing it by value (and occasionally cloning it), we now just create the RNG at the top of a commend when we need it. This has the drawback of potentially creating too many RNGs (especially in a close flow), which could lead to them being seeded without enough entropy.
A proper solution to this problem should do the following
clone.Commandor give ownership (and requirecloning).