| Age | Commit message (Collapse) | Author |
|---|
|
Specifically, change the ptr_t typedefs for these LLCore classes to use
IntrusivePtr rather than directly using boost::intrusive_ptr. This allows us
to use a simple ptr_t(raw ptr) constructor rather than having to remember to
code ptr_t(raw ptr, false) everywhere. In fact, the latter form is now invalid:
remove the now-extraneous 'false' constructor parameters.
|
|
For a RefCounted subclass T, boost::intrusive_ptr<T> must be instantiated as
boost::intrusive_ptr<T>(raw ptr, false) to avoid immortal instances.
Forgetting that final bool parameter is both easy and extremely hard to spot
with desk checking or code review. IntrusivePtr<T> provides constructors that
Do The Right Thing, so we can typedef a subclass T's ptr_t to IntrusivePtr<T>
rather than directly to boost::intrusive_ptr<T>.
|
|
|
|
This allows engaging slshare-service debug logging for a particular viewer
session without having to twiddle the slshare-service hosts.
Also fix leaky LLCore::HttpHeaders::ptr_t construction.
|
|
|
|
clang doesn't like finding HttpCoroutineAdapter::postFileAndYield(...) inside
the class definition for HttpCoroutineAdapter. It's much happier with plain
postFileAndYield(...).
|
|
|
|
|
|
|
|
We've had this functionality buried in llerror.cpp for years. Make it
available for callers outside llerror.cpp too.
|
|
LLSingleton explicitly supports circular dependencies: initialization
performed during an LLSingleton subclass's initSingleton() method may
recursively call that same subclass's getInstance() method. On the other hand,
circularity from a subclass constructor cannot be permitted, else
getInstance() would have to return a partially-constructed object.
Our dependency tracking circularity check initially forbade both. Loosen it to
permit references from within initSingleton().
|
|
|
|
|
|
|
|
llhttpclientadapter_test.cpp starts its every test by explicitly instantiating
a local LLHTTPClientAdapter object. This is an abuse of LLSingleton, and if it
had been properly defined (private constructor), it should never have compiled.
Looked at the other way, though, every known reference to LLHTTPClientAdapter
instantiates a local object. Why did someone think it should be an LLSingleton
in the first place? Remove LLSingleton<> as a base class; remove llsingleton.h.
This makes llhttpclientadapter_test.cpp work just fine.
One might also question what value this class adds. It seems to do very little
-- but more significantly, the ONLY references in the source tree are its
declaration, definition and test. Nobody actually uses it anywhere.
|
|
The forward declaration said it was a 'friend class', whereas the actual
definition is a struct. MSVC dislikes that.
|
|
Part of LLError's logging infrastructure is implemented with an LLSingleton.
Therefore, attempts to log from within LLSingleton machinery could potentially
go south if LLError's LLSingleton is not yet initialized.
Introduce LLError::is_available() in llerrorcontrol.h and llerror.cpp.
Make LLSingletonBase::logwarns() and logerrs() consult LLError::is_available()
before attempting to use LL_WARNS or LL_ERRS, respectively.
Moreover, make all LLSingleton internal logging use logwarns() and logerrs()
instead of directly engaging LL_ERRS or LL_WARNS.
|
|
|
|
Introduce LLSingleton::cleanupSingleton() canonical method as the place to put
any subclass cleanup logic that might take nontrivial realtime or throw an
exception. Neither is appropriate in a destructor.
Track all extant LLSingleton subclass instances on a master list, which
permits adding LLSingletonBase::cleanupAll() and deleteAll() methods.
Also notice when any LLSingleton subclass constructor (or initSingleton()
method) calls instance() or getInstance() for another LLSingleton, and capture
that other LLSingleton instance as a dependency of the first. This permits
cleanupAll() and deleteAll() to perform a dependency sort on the master list,
thus cleaning up (or deleting) leaf LLSingletons AFTER the LLSingletons that
depend on them.
Make C++ runtime's final static destructor call LLSingletonBase::deleteAll()
instead of deleting individual LLSingleton instances in arbitrary order.
Eliminate "llerror.h" from llsingleton.h, a longstanding TODO.
|
|
|
|
|
|
|
|
only 254
|
|
are selected.
|
|
|
|
|
|
|
|
party scripts
|
|
|
|
|
|
|
|
favorite login locations
|
|
change before promoting
|
|
|
|
for directories as well as for files.
|
|
|
|
framework vs copying in second version
|
|
improved build script for its third party library
|
|
didn't catch it.
|
|
The default behavior in the HTTP layer changed to follow redirects automatically.
This was causing a problem with connecting to the SL share service which was attempting to
riderect to the login page at the CURL level. Connections to SL Share will no longer redirect,
corrected for Facebook, Flickr and Twitter.
|
|
|
|
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
|
http://bit.ly/1R8WhaY
|
