summaryrefslogtreecommitdiff
path: root/indra/llcommon
AgeCommit message (Collapse)Author
2020-03-25DRTVWR-494: Move LL_ERRS out of llinstancetracker.h header file.Nat Goodspeed
Add a namespaced free function in .cpp file to report LL_ERRS as needed. Per code review, use a more indicative namespace name.
2020-03-25DRTVWR-494: Move explanatory comments from LLSingleton to LockStatic.Nat Goodspeed
2020-03-25DRTVWR-494: Add llmake_heap(); update to variadic llmake().Nat Goodspeed
2020-03-25DRTVWR-494: Extract LockStatic as a standalone template class.Nat Goodspeed
The pattern of requiring a lock to permit *any* access to a static instance of something seems generally useful. Break out lockstatic.h; recast LLInstanceTracker to use it. Moving LockStatic to an external template class instead of a nested class in LLInstanceTrackerBase leaves LLInstanceTrackerBase pretty empty. Get rid of it. And *that* means we can move the definition of the StaticData used by each LLInstanceTracker specialization into the class itself, rather than having to define it beforehand in namespace LLInstanceTrackerStuff.
2020-03-25DRTVWR-494: Streamline LLSingleton state machine.Nat Goodspeed
The CONSTRUCTED state was only briefly set between constructSingleton() and finishInitializing(). But as no consumer code is executed between setting CONSTRUCTED and setting INITIALIZING, it was impossible to reach the switch statement in either getInstance() method in state CONSTRUCTED. So there was no point in state CONSTRUCTED. Remove it. With CONSTRUCTED gone, we only ever call finishInitializing() right after constructSingleton(). Merge finishInitializing() into constructSingleton().
2020-03-25DRTVWR-494: Encapsulate redundant VS boilerplate around <mutex>.Nat Goodspeed
2020-03-25DRTVWR-494: Streamline LLEventTimer::updateClass().Nat Goodspeed
No need to capture a separate list of completed LLEventTimer instances to delete after the primary loop, since at this point we're looping over a snapshot and can directly delete each completed timer.
2020-03-25DRTVWR-494: Add on_main_thread(), sibling to assert_main_thread().Nat Goodspeed
2020-03-25DRTVWR-494: Improve thread safety of LLSingleton machinery.Nat Goodspeed
Remove warnings about LLSingleton not being thread-safe because, at this point, we have devoted considerable effort to trying to make it thread-safe. Add LLSingleton<T>::Locker, a nested class which both provides a function- static mutex and a scoped lock that uses it. Instantiating Locker, which has a nullary constructor, replaces the somewhat cumbersome idiom of declaring a std::unique_lock<std::recursive_mutex> lk(getMutex); This eliminates (or rather, absorbs) the typedefs and getMutex() method from LLParamSingleton. Replace explicit std::unique_lock declarations in LLParamSingleton methods with Locker declarations. Remove LLSingleton<T>::SingletonInitializer nested struct. Instead of getInstance() relying on function-static initialization to protect (only) constructSingleton() calls, explicitly use a Locker instance to cover its whole scope, and make the UNINITIALIZED case call constructSingleton(). Rearrange cases so that after constructSingleton(), control falls through to the CONSTRUCTED case and the finishInitializing() call. Use a Locker instance in other public-facing methods too: instanceExists(), wasDeleted(), ~LLSingleton(). Make destructor protected so it can only be called via deleteSingleton() (but must be accessible to subclasses for overrides). Remove LLSingletonBase::get_master() and get_initializing(), which permitted directly manipulating the master list and the initializing stack without any locking mechanism. Replace with get_initializing_size(). Similarly, replace LLSingleton_manage_master::get_initializing() with get_initializing_size(). Use in constructSingleton() in place of get_initializing().size(). Remove LLSingletonBase::capture_dependency()'s list_t parameter, which accepted the list returned by get_initializing(). Encapsulate that retrieval within the scope of the new lock in capture_dependency(). Add LLSingleton_manage_master::capture_dependency(LLSingletonBase*, EInitState) to forward (or not) a call to LLSingletonBase::capture_dependency(). Nullary LLSingleton<T>::capture_dependency() calls new LLSingleton_manage_master method. Equip LLSingletonBase::MasterList with a mutex of its own, separate from the one donated by the LLSingleton machinery, to serialize use of MasterList data members. Introduce MasterList::Lock nested class to lock the MasterList mutex while providing a reference to the MasterList instance. Introduce subclasses LockedMaster, which provides a reference to the actual mMaster master list while holding the MasterList lock; and LockedInitializing, which does the same for the initializing list. Make mMaster and get_initializing_() private so that consuming code can *only* access those lists via LockedInitializing and LockedMaster. Make MasterList::cleanup_initializing_() private, with a LockedInitializing public forwarding method. This avoids another call to MasterList::instance(), and also mandates that the lock is currently held during every call. Similarly, move LLSingletonBase::log_initializing() to a LockedInitializing log() method. (transplanted from dca0f16266c7bddedb51ae7d7dca468ba87060d5)
2020-03-25DRTVWR-494: Quiet VS warnings about its own <mutex> header.Nat Goodspeed
2020-03-25DRTVWR-494: Defend LLInstanceTracker against multi-thread usage.Nat Goodspeed
The previous implementation went to some effort to crash if anyone attempted to create or destroy an LLInstanceTracker subclass instance during traversal. That restriction is manageable within a single thread, but becomes unworkable if it's possible that a given subclass might be used on more than one thread. Remove LLInstanceTracker::instance_iter, beginInstances(), endInstances(), also key_iter, beginKeys() and endKeys(). Instead, introduce key_snapshot() and instance_snapshot(), the only means of iterating over LLInstanceTracker instances. (These are intended to resemble functions, but in fact the current implementation simply presents the classes.) Iterating over a captured snapshot defends against container modifications during traversal. The term 'snapshot' reminds the coder that a new instance created during traversal will not be considered. To defend against instance deletion during traversal, a snapshot stores std::weak_ptrs which it lazily dereferences, skipping on the fly any that have expired. Dereferencing instance_snapshot::iterator gets you a reference rather than a pointer. Because some use cases want to delete all existing instances, add an instance_snapshot::deleteAll() method that extracts the pointer. Those cases used to require explicitly copying instance pointers into a separate container; instance_snapshot() now takes care of that. It remains the caller's responsibility to ensure that all instances of that LLInstanceTracker subclass were allocated on the heap. Replace unkeyed static LLInstanceTracker::getInstance(T*) -- which returned nullptr if that instance had been destroyed -- with new getWeak() method returning std::weak_ptr<T>. Caller must detect expiration of that weak_ptr. Adjust tests accordingly. Use of std::weak_ptr to detect expired instances requires engaging std::shared_ptr in the constructor. We now store shared_ptrs in the static containers (std::map for keyed, std::set for unkeyed). Make LLInstanceTrackerBase a template parameterized on the type of the static data it manages. For that reason, hoist static data class declarations out of the class definitions to an LLInstanceTrackerStuff namespace. Remove the static atomic sIterationNestDepth and its methods incrementDepth(), decrementDepth() and getDepth(), since they were used only to forbid creation and destruction during traversal. Add a std::mutex to static data. Introduce an internal LockStatic class that locks the mutex while providing a pointer to static data, making that the only way to access the static data. The LLINSTANCETRACKER_DTOR_NOEXCEPT macro goes away because we no longer expect ~LLInstanceTracker() to throw an exception in test programs. That affects LLTrace::StatBase as well as LLInstanceTracker itself. Adapt consumers to the new LLInstanceTracker API.
2019-12-16Merge viewer-release 6.3.6 into viewwer-eep repoDave Houlton
2019-11-27Upstream merge from viewer-nekoAndreyL ProductEngine
2019-11-27Downstream merge from lindenlab/viewer-lynxAndreyL ProductEngine
2019-11-19SL-6621 Small rework, should also fix mNumTotalRef related assertsandreykproductengine
2019-11-13Merge in from viewer-release 6.3.5Dave Houlton
2019-11-12Merged in lindenlab/viewer-releaseAndreyL ProductEngine
2019-11-10SL-6109 Better key and table localization support and fix for key-replacingandreykproductengine
2019-10-23SL-11727 Fix build warningsandreykproductengine
2019-10-16mergeBrad Payne (Vir Linden)
2019-10-15Merge from viewer-releaseandreykproductengine
2019-10-03SL-6109 Remade 'ignore' list processing, renamed and reformed keybindingsandreykproductengine
2019-09-26SL-6109 Conflict resolutionandreykproductengine
2019-09-25when using bugsplat, do not catch SIGABRT; also, fix signal setting in Mac ↵Oz Linden
(broken macro)
2019-09-25remove fatal error hook usage from LLLeap (potential races for multiple ↵Oz Linden
processes)
2019-09-25SL-6109 Mouse support readyandreykproductengine
2019-09-24further simplify function pointer loggingOz Linden
2019-09-24simplify function pointer loggingOz Linden
2019-09-24improve fatal hook loggingOz Linden
2019-09-24log calls that modify the fatal error hookOz Linden
2019-09-17SL-6109 Keyaboard support readyandreykproductengine
2019-09-10Merge viewer-release 6.3.2Graham Linden
2019-09-10Merged in lindenlab/viewer-releaseandreykproductengine
2019-09-05Merged in lindenlab/viewer-bearAndreyL ProductEngine
2019-09-05Merged in lindenlab/viewer-lynxAndreyL ProductEngine
2019-08-29Merge from lindenlab/viewer-releaseandreykproductengine
2019-08-26Merge 6.3.1 viewer-releaseGraham Linden
2019-08-26Merged in lindenlab/viewer-releaseAndreyL ProductEngine
2019-08-20Automated merge with ssh://bitbucket.org/andreykproductengine/drtvwr-493Nat Goodspeed
2019-08-20DRTVWR-493: Clarify capturing LLError::getFatalFunction() in a var.Nat Goodspeed
VS 2013 thought we were storing an initialization-list.
2019-08-20DRTVWR-493: Defend LL[Param]Singleton against ctor/init exceptions.Nat Goodspeed
An exception in the LLSingleton subclass constructor, or in its initSingleton() method, could leave the LLSingleton machinery in a bad state: the failing instance would remain in the MasterList, also on the stack of initializing LLSingletons. Catch exceptions in either and perform relevant cleanup. This problem is highlighted by test programs, in which LL_ERRS throws an exception rather than crashing the whole process. In the relevant catch clauses, clean up the initializing stack BEFORE logging. Otherwise we get tangled up recording bogus dependencies. Move capture_dependency() out of finishInitializing(): it must be called by every valid getInstance() call, both from LLSingleton and LLParamSingleton. Introduce new CONSTRUCTED EInitState value to distinguish "have called the constructor but not yet the initSingleton() method" from "currently within initSingleton() method." This is transient, but we execute the 'switch' on state within that moment. One could argue that the previous enum used INITIALIZING for current CONSTRUCTED, and INITIALIZED meant INITIALIZING too, but this is clearer. Introduce template LLSingletonBase::classname() helper methods to clarify verbose demangle(typeid(stuff).name()) calls. Similarly, introduce LLSingleton::pop_initializing() shorthand method.
2019-09-19SL-6109 Implement keybindingsandreykproductengine
2019-08-19DRTVWR-493: Improve exception safety of LLSingleton initialization.Nat Goodspeed
Add try/catch clauses to constructSingleton() (to catch exceptions in the subclass constructor) and finishInitializing() (to catch exceptions in the subclass initSingleton() method). Each of these catch clauses rethrows the exception -- they're for cleanup, not for ultimate handling. Introduce LLSingletonBase::reset_initializing(list_t::size_t). The idea is that since we can't know whether the exception happened before or after the push_initializing() call in LLSingletonBase's constructor, we can't just pop the stack. Instead, constructSingleton() captures the stack size before attempting to construct the new LLSingleton subclass. On exception, it calls reset_initializing() to restore the stack to that size. Naturally that requires a corresponding LLSingleton_manage_master method, whose MasterList specialization is a no-op. finishInitializing()'s exception handling is a bit simpler because it has a constructed LLSingleton subclass instance in hand, therefore push_initializing() has definitely been called, therefore it can call pop_initializing(). Break out new static capture_dependency() method from finishInitializing() because, in the previous LLSingleton::getInstance() implementation, the logic now wrapped in capture_dependency() was reached even in the INITIALIZED case. TODO: Add a new EInitState to differentiate "have been constructed, now calling initSingleton()" from "fully initialized, normal case" -- in the latter control path we should not be calling capture_dependency(). The LLSingleton_manage_master<LLSingletonBase::MasterList> specialization's get_initializing() function (which called get_initializing_from()) was potentially dangerous. get_initializing() is called by push_initializing(), which (in the general case) is called by LLSingletonBase's constructor. If somehow the MasterList's LLSingletonBase constructor ended up calling get_initializing(), it would have called get_initializing_from(), passing an LLSingletonBase which had not yet been constructed into the MasterList. In particular, its mInitializing map would not yet have been initialized at all. Since the MasterList must not, by design, depend on any other LLSingletons, LLSingleton_manage_master<LLSingletonBase::MasterList>::get_initializing() need not return a list from the official mInitializing map anyway. It can, and should, and now does, return a static dummy list. That obviates get_initializing_from(), which is removed. That in turn means we no longer need to pass get_initializing() an LLSingletonBase*. Remove that parameter.
2019-08-14DRTVWR-493: Work around static initialization order problem.Nat Goodspeed
LLParamSingleton contained a static member mutex. Unfortunately that wasn't guaranteed to be initialized by the time its getInstance() was entered. Use a function-local static instead.
2019-08-13DRTVWR-493 Test fix for W64andreykproductengine
2019-08-12DRTVWR-493: Rely on recursive_mutex to handle circularityNat Goodspeed
from LLParamSingleton::initSingleton().
2019-08-12Automated merge with ssh://bitbucket.org/andreykproductengine/drtvwr-493Nat Goodspeed
2019-08-12DRTVWR-493: Permit LLParamSingleton::initSingleton() circularity.Nat Goodspeed
This was forbidden, but AndreyK points out cases in which LLParamSingleton:: initSingleton() should in fact be allowed to circle back to its own instance() method. Use a recursive_mutex instead of plain mutex to permit that; remove LL_ERRS preventing it. Add LLParamSingleton::instance() method that calls LLParamSingleton::getInstance(). Inheriting LLSingleton::instance() called LLSingleton::getInstance() -- not at all what we want. Add LLParamSingleton unit tests.
2019-08-12DRTVWR-493 LLWearableType to LLParamSingletonandreykproductengine
2019-08-12Automated merge with file:///Users/nat/linden/viewer-catchNat Goodspeed