From the work done in WT-11532, each random cursor will maintain it's own random seed.
WT_ERR(__wt_config_gets_def(session, cfg, "next_random_seed", 0, &cval)); if (cval.val != 0) __wt_random_init_custom_seed(&cbt->rnd, (uint64_t)cval.val); else __wt_random_init_seed(session, &cbt->rnd);
We now call __wt_random_init_seed which will use the default seed we have and combine it with the thread ID and time. This change makes it hard to diagnose and root cause when a failure comes that deals with the random cursor. This ticket investigates into finding a method that somehow can log the seed or find some more reproducible way to diagnose these future problems. Note that the __wt_random_init_custom_seed function doesn't directly set the seeds as well.
void
__wt_random_init_custom_seed(WT_RAND_STATE volatile *rnd_state, uint64_t v)
WT_GCC_FUNC_ATTRIBUTE((visibility("default")))
{
WT_RAND_STATE rnd;
/*
* XOR the provided seed with the initial seed. With high probability, this would provide a
* random-looking seed which has about 50% of the bits turned on. We don't need to check whether
* W or Z becomes 0, because we would handle it the first time we use this state to generate a
* random number.
*/
M_V(rnd) = v;
M_W(rnd) ^= DEFAULT_SEED_W;
M_Z(rnd) ^= DEFAULT_SEED_Z;
*rnd_state = rnd;
}
- related to
-
WT-11532 Fix session reset RNG by using cursor RNG
-
- Closed
-