Age | Commit message (Collapse) | Author |
|
LLRandFlagFib2281 needs a lot of space in the TLB, which is usually fine. Unless libcef gets loaded...
CEF is compiled with static TLS/TLS model initial-exec and then having gRandomGenerator allocation so much space in the TLB will exhaust the available space and CEF cannot be loaded.
|
|
and llunittype.h for now
|
|
LF, and trim trailing whitespaces as needed
|
|
|
|
by making it thread_local.
|
|
|
|
|
|
With GitHub viewer builds, every few weeks we've seen test failures when
ll_frand() returns exactly 1.0. This is a problem for a function that's
supposed to return [0.0 .. 1.0).
Monty suggests that the problem is likely to be conversion of F32 to F64 to
pass to fmod(), and then truncation of fmod()'s F64 result back to F32. Moved
the clamping code to each size-specific ll_internal_random specialization.
Monty also noted that a stateful static random number engine isn't
thread-safe. Added a mutex lock.
|
|
LL_USE_SYSTEM_RAND has been disabled since June 2008; that code only clutters
the implementation we actually use.
|
|
|
|
|
|
|
|
|
|
svn+ssh://svn/svn/user/phoenix/license_2009_merge into trunk. QAR-1165
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/cmake-9-merge
dataserver-is-deprecated
for-fucks-sake-whats-with-these-commit-markers
|