Go to file
Nat Goodspeed 310db14bee DRTVWR-493: Improve exception safety of LLSingleton initialization.
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-19 11:44:56 -04:00
debian
…
doc SL-11079 Updated contributions.txt 2019-05-28 23:52:23 +03:00
etc SL-694 - stub support for ObjectAnimation message type 2017-05-30 22:03:43 +01:00
indra DRTVWR-493: Improve exception safety of LLSingleton initialization. 2019-08-19 11:44:56 -04:00
scripts merge 2018-09-27 19:54:10 +01:00
.hgignore
…
.hgtags Added tag 6.2.3-release for changeset ab2ec5c5423b 2019-06-20 14:18:41 -04:00
BuildParams remove duplicated EDU definitions 2018-09-05 09:12:21 -04:00
README.md dummy checkin to build an upgrade target 2017-05-17 18:10:43 -07:00
autobuild.xml Pull in a change to Dullahan that allows user to specify flag that lets video/audio autoplay like it did before Chrome 70? (Dullahan v1.1.1320). Also sets a flag in media plugin CEF code to change the settings from false (default) to true 2019-03-18 15:36:16 -07:00
build.sh SL-957: Convert absolute VIEWER_SYMBOL_FILE to native_path. 2018-08-31 16:59:59 -04:00

README.md

Second Life Viewer

This project manages the source code for the Second Life Viewer.

This source is available as open source; for details on licensing, see the licensing page on the Second Life wiki

For information on how to use and contribute to this, see the open source portal on the wiki.

To download the current default version, visit the download page. For even newer versions try the Alternate Viewers page