Fix transient failures in unit_seedable_global_PRNG.

[bekadavis9]

Fix transient failures in unit_seedable_global_PRNG.

[sc-51470]

---

TYPE: BUG
DESC: Fix transient failures in unit_seedable_global_PRNG.

[davisp]

If this test is being flaky, I'd probably suggest going and adding the ability to provide a custom clock source into the instances so that in tests you can provide a controlled clock value. That way all the behavior can be tested without respect to the capabilities of the hardware running the tests.

I'm not entirely caffeinated, so take this with a grain of salt, but I think you could manage this using a slight tweak to the existing RandomLabelGenerator be moving time generation into a virtual method that could be overridden by a test subclass. Or, alternatively if we want to avoid virtual method dispatch in this code loop, rename RandomLabelGenerator::generate() to something like RandomLabelGenerator::do_generate(uint64_t curr_timestamp) and then add a new RandomLabelGenerator::generate() that gets the current time and passes it as an argument.

[eric-hughes-tiledb]

provide a custom clock source

This the technique of using a mock object to get a deterministic test. One of the problems with the test is that the way it's currently written it's sensitive to computation speed. One way to deal with it would be to create the ability to mock the current time. Another way would be to make the test rate-limited, so that it's insensitive to how fast the computation runs (with some lower bound, clearly).

moving time generation into a virtual method

This mechanism, and also the others suggested, are all ways of using dynamic polymorphism, i.e. at run-time, to create mocks. It's more effective to use to static polymorphism at compile time. The technique uses policy template arguments to define what clock to use. The default policy uses the standard clock. A test policy uses a test-oriented clock, presumably with a side channel to the test framework that can control its behavior.

This PR is about fixing this one particular test. It seems like overkill to set up any mock support in the class for it. I'm certainly not against the idea in general, but it's not at all clear we need to incur its development cost in this particular case.

[davisp]

Seems easy enough to me to remove the clock dependency:

f68538f

[davisp]

+1