summaryrefslogtreecommitdiff
path: root/indra/llcommon/llrand.cpp
diff options
context:
space:
mode:
authorAndrey Lihatskiy <118752495+marchcat@users.noreply.github.com>2025-12-04 00:30:33 +0200
committerGitHub <noreply@github.com>2025-12-04 00:30:33 +0200
commit8c134d5a4a9f08a87104530fe910bc39434cacf2 (patch)
treedad5ddf6daf7f5e1bc7b47cd670a99ca73d4c5a1 /indra/llcommon/llrand.cpp
parent2c3ce8fb8ce3967d957e13d48627b45dd32f0e00 (diff)
parent590f58dbad3dc3db3482dba86bf2619a87a7dad5 (diff)
Merge pull request #5020 from secondlife/marchcat/slua-linux
develop-linux → SLua PV merge
Diffstat (limited to 'indra/llcommon/llrand.cpp')
-rw-r--r--indra/llcommon/llrand.cpp25
1 files changed, 21 insertions, 4 deletions
diff --git a/indra/llcommon/llrand.cpp b/indra/llcommon/llrand.cpp
index 2c51e6f07f..513613f543 100644
--- a/indra/llcommon/llrand.cpp
+++ b/indra/llcommon/llrand.cpp
@@ -58,9 +58,26 @@
* to restore uniform distribution.
*/
-// gRandomGenerator is a stateful static object, which is therefore not
+// pRandomGenerator is a stateful static object, which is therefore not
// inherently thread-safe.
-static thread_local LLRandLagFib2281 gRandomGenerator(LLUUID::getRandomSeed());
+//We use a pointer to not construct a huge object in the TLS space, sadly this is necessary
+// due to libcef.so on Linux being compiled with TLS model initial-exec (resulting in
+// FLAG STATIC_TLS, see readelf libcef.so). CEFs own TLS objects + LLRandLagFib2281 then will exhaust the
+// available TLS space, causing media failure.
+
+static thread_local std::unique_ptr< LLRandLagFib2281 > pRandomGenerator = nullptr;
+
+namespace {
+ F64 ll_internal_get_rand()
+ {
+ if( !pRandomGenerator )
+ {
+ pRandomGenerator.reset(new LLRandLagFib2281(LLUUID::getRandomSeed( ) ));
+ }
+
+ return(*pRandomGenerator)();
+ }
+}
// no default implementation, only specific F64 and F32 specializations
template <typename REAL>
@@ -73,7 +90,7 @@ inline F64 ll_internal_random<F64>()
// CPUs (or at least multi-threaded processes) seem to
// occasionally give an obviously incorrect random number -- like
// 5^15 or something. Sooooo, clamp it as described above.
- F64 rv{ gRandomGenerator() };
+ F64 rv{ ll_internal_get_rand() };
if(!((rv >= 0.0) && (rv < 1.0))) return fmod(rv, 1.0);
return rv;
}
@@ -85,7 +102,7 @@ inline F32 ll_internal_random<F32>()
// Per Monty, it's important to clamp using the correct fmodf() rather
// than expanding to F64 for fmod() and then truncating back to F32. Prior
// to this change, we were getting sporadic ll_frand() == 1.0 results.
- F32 rv{ narrow<F64>(gRandomGenerator()) };
+ F32 rv{ narrow<F64>(ll_internal_get_rand()) };
if(!((rv >= 0.0f) && (rv < 1.0f))) return fmodf(rv, 1.0f);
return rv;
}