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
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