On Mon, 11 Sep 2023 11:00:46 +0200 Mattias Rönnblom <hof...@lysator.liu.se> wrote:
> > uint64_t rte_rand_r(struct rte_rand_state * const state); > > void rte_srand_r(struct rte_rand_state * const state, uint64_t > > seed); uint64_t rte_rand_max_r(struct rte_rand_state * const state, > > uint64_t upper_bound); double rte_drand_r(struct rte_rand_state * > > const state, void); > > > > For this to work, we would have to make struct rte_rand_state > > public, and the application would need to allocate it. (At least > > one instance per thread that uses it, obviously.) > > Yes, and that will come at a pretty severe API complexity cost. > > Besides the obvious complexities, it may also lead the user to > believe the rte_rand() is not MT safe for any thread, since that's > how it works in glibc (rand() versus rand_r()). Actual rand state implementation could be hidden by having an allocation/create/new function.
