summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNat Goodspeed <nat@lindenlab.com>2019-12-03 12:49:18 -0500
committerNat Goodspeed <nat@lindenlab.com>2020-03-25 15:28:17 -0400
commit794072c1415e986b95cab65f8217857263d7468a (patch)
treecc57840051221e914281359165a7d5aae5b2b73e
parentb080b06b422db6405982bee603118ee68e6c2500 (diff)
DRTVWR-494: Streamline LLSingleton state machine.
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().
-rw-r--r--indra/llcommon/llsingleton.h24
1 files changed, 0 insertions, 24 deletions
diff --git a/indra/llcommon/llsingleton.h b/indra/llcommon/llsingleton.h
index 4efffde43a..ebae601029 100644
--- a/indra/llcommon/llsingleton.h
+++ b/indra/llcommon/llsingleton.h
@@ -57,7 +57,6 @@ protected:
{
UNINITIALIZED = 0, // must be default-initialized state
CONSTRUCTING, // within DERIVED_TYPE constructor
- CONSTRUCTED, // finished DERIVED_TYPE constructor
INITIALIZING, // within DERIVED_TYPE::initSingleton()
INITIALIZED, // normal case
DELETED // deleteSingleton() or deleteAll() called
@@ -355,7 +354,6 @@ private:
{
sData.mInstance = new DERIVED_TYPE(std::forward<Args>(args)...);
// we have called constructor, have not yet called initSingleton()
- sData.mInitState = CONSTRUCTED;
}
catch (const std::exception& err)
{
@@ -373,10 +371,7 @@ private:
// propagate the exception
throw;
}
- }
- static void finishInitializing()
- {
// getInstance() calls are from within initSingleton()
sData.mInitState = INITIALIZING;
try
@@ -506,11 +501,6 @@ public:
case UNINITIALIZED:
constructSingleton();
- // fall through...
-
- case CONSTRUCTED:
- // still have to call initSingleton()
- finishInitializing();
break;
case INITIALIZING:
@@ -526,7 +516,6 @@ public:
classname<DERIVED_TYPE>().c_str(),
" -- creating new instance");
constructSingleton();
- finishInitializing();
break;
}
@@ -625,7 +614,6 @@ public:
else
{
super::constructSingleton(std::forward<Args>(args)...);
- super::finishInitializing();
}
}
@@ -648,18 +636,6 @@ public:
" from singleton constructor!");
break;
- case super::CONSTRUCTED:
- // Should never happen!? The CONSTRUCTED state is specifically to
- // navigate through LLSingleton::SingletonInitializer getting
- // constructed (once) before LLSingleton::getInstance()'s switch
- // on mInitState. But our initParamSingleton() method calls
- // constructSingleton() and then calls finishInitializing(), which
- // immediately sets INITIALIZING. Why are we here?
- super::logerrs("Param singleton ",
- super::template classname<DERIVED_TYPE>().c_str(),
- "::initSingleton() not yet called");
- break;
-
case super::INITIALIZING:
// As with LLSingleton, explicitly permit circular calls from
// within initSingleton()