summaryrefslogtreecommitdiff
path: root/indra
diff options
context:
space:
mode:
authorNat Goodspeed <nat@lindenlab.com>2016-08-31 16:20:10 -0400
committerNat Goodspeed <nat@lindenlab.com>2016-08-31 16:20:10 -0400
commit959edebeca3c1d9f0730292c2f3bc0e8bb5bf94a (patch)
tree3080d0bbcfdfeab16b1d586e6eec2b0fca56cf7d /indra
parent334eb89d8e993c05511f858b6a36732e7dd659df (diff)
MAINT-5232: Add LLSingletonBase::cleanupAll() and deleteAll() calls
near the end of LLAppViewer::cleanup() so every LLSingleton class that hasn't already been explicitly cleaned up gets a chance to perform its own cleanup.
Diffstat (limited to 'indra')
-rw-r--r--indra/newview/llappviewer.cpp30
1 files changed, 27 insertions, 3 deletions
diff --git a/indra/newview/llappviewer.cpp b/indra/newview/llappviewer.cpp
index 63e9788c6f..bddc50746a 100644
--- a/indra/newview/llappviewer.cpp
+++ b/indra/newview/llappviewer.cpp
@@ -2100,10 +2100,34 @@ bool LLAppViewer::cleanup()
LLError::LLCallStacks::cleanup();
removeMarkerFiles();
-
- LL_INFOS() << "Goodbye!" << LL_ENDL;
- removeDumpDir();
+ // It's not at first obvious where, in this long sequence, generic cleanup
+ // calls OUGHT to go. So let's say this: as we migrate cleanup from
+ // explicit hand-placed calls into the generic mechanism, eventually
+ // all cleanup will get subsumed into the generic calls. So the calls you
+ // still see above are calls that MUST happen before the generic cleanup
+ // kicks in.
+
+ // This calls every remaining LLSingleton's cleanupSingleton() method.
+ // This method should perform any cleanup that might take significant
+ // realtime, or might throw an exception.
+ LLSingletonBase::cleanupAll();
+
+ // This calls every remaining LLSingleton's deleteSingleton() method.
+ // No class destructor should perform any cleanup that might take
+ // significant realtime, or throw an exception.
+ // LLSingleton machinery includes a last-gasp implicit deleteAll() call,
+ // so this explicit call shouldn't strictly be necessary. However, by the
+ // time the runtime engages that implicit call, it may already have
+ // destroyed things like std::cerr -- so the implicit deleteAll() refrains
+ // from logging anything. Since both cleanupAll() and deleteAll() call
+ // their respective cleanup methods in computed dependency order, it's
+ // probably useful to be able to log that order.
+ LLSingletonBase::deleteAll();
+
+ LL_INFOS() << "Goodbye!" << LL_ENDL;
+
+ removeDumpDir();
// return 0;
return true;