g_random_xxx() could avoid locking to be faster
Randomized algorithms, such as GLib's own GSequence
, hunger for high-volume high-quality random numbers. It's nice that GLib has a handy mersenne twister implementation.
Managing private instances could be cumbersome: for example, it is not practical to create one GRand
per GSequence
. This is where an easy to use g_random_int()
etc shine.
However, currently this function uses a lock internally to be thread-safe. This reduces its performance, and can introduce queues if multiple threads try to use it simultaneously. This can be improved if it will use a GPrivate
based per-thread instance instead of lock.
A drawback is that one more GPrivate
is used, and these have a limit. However, I understand that currently the limit is still far away, and the limit can be removed completely via #2473
Currently this issue is a blocker for a GSequence fix