summaryrefslogtreecommitdiff
path: root/indra/llmessage/llproxy.h
AgeCommit message (Collapse)Author
2020-03-25DRTVWR-494: Use std::thread::id for LLThread::currentID().Nat Goodspeed
LLThread::currentID() used to return a U32, a distinct unsigned value incremented by explicitly constructing LLThread or by calling LLThread:: registerThreadID() early in a thread launched by other means. The latter imposed an unobvious requirement on new code based on std::thread. Using std::thread::id instead delegates to the compiler/library the problem of distinguishing threads launched by any means. Change lots of explicit U32 declarations. Introduce LLThread::id_t typedef to avoid having to run around fixing uses again if we later revisit this decision. LLMutex, which stores an LLThread::id_t, wants a distinguished value meaning NO_THREAD, and had an enum with that name. But as std::thread::id promises that the default-constructed value is distinct from every valid value, NO_THREAD becomes unnecessary and goes away. Because LLMutex now stores LLThread::id_t instead of U32, make llmutex.h #include "llthread.h" instead of the other way around. This makes LLMutex an incomplete type within llthread.h, so move LLThread::lockData() and unlockData() to the .cpp file. Similarly, remove llrefcount.h's #include "llmutex.h" to break circularity; instead forward-declare LLMutex. It turns out that a number of source files assumed that #include "llthread.h" would get the definition for LLMutex. Sprinkle #include "llmutex.h" as needed. In the SAFE_SSL code in llcorehttp/httpcommon.cpp, there's an ssl_thread_id() callback that returns an unsigned long to the SSL library. When LLThread:: currentID() was U32, we could simply return that. But std::thread::id is very deliberately opaque, and can't be reinterpret_cast to unsigned long. Fortunately it can be hashed because std::hash is specialized with that type.
2019-01-15SL-10291 Replace apr_atomic with standard C++11 functionalityandreykproductengine
2016-09-15MAINT-5232: Normalize LLSingleton subclasses.Nat Goodspeed
A shocking number of LLSingleton subclasses had public constructors -- and in several instances, were being explicitly instantiated independently of the LLSingleton machinery. This breaks the new LLSingleton dependency-tracking machinery. It seems only fair that if you say you want an LLSingleton, there should only be ONE INSTANCE! Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the friend class LLSingleton<whatevah>; and explicitly declare a private nullary constructor. To try to enforce the LLSINGLETON() convention, introduce a new pure virtual LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might suspect, defined by the macro. If you declare an LLSingleton subclass without using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro() implementation -- which will hopefully remind the coder. Trawl through ALL LLSingleton subclass definitions, sprinkling in LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit constructor declarations, public or private, along with relevant 'friend class LLSingleton<myself>' declarations. Where destructors are declared, move them into private section as well. Where the constructor was inline but nontrivial, move out of class body. Fix several LLSingleton abuses revealed by making ctors/dtors private: LLGlobalEconomy was both an LLSingleton and the base class for LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance contained another instance of the LLGlobalEconomy "singleton.") Extract LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that. LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy. LLToolGrab, an LLSingleton, was also explicitly instantiated by LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated, with trivial subclass LLToolGrab, the LLSingleton instance. (WARNING: LLToolGrabBase methods have an unnerving tendency to go after LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship between the instance in LLToolCompGun and the LLToolGrab singleton instance.) LLGridManager declared a variant constructor accepting (const std::string&), with the comment: // initialize with an explicity grid file for testing. As there is no evidence of this being called from anywhere, delete it. LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD parameter wasn't used, and as there is no evidence of it being passed from anywhere, delete the parameter. LLViewerWindow::shutdownViews() was checking LLNavigationBar:: instanceExists(), then deleting its getInstance() pointer -- leaving a dangling LLSingleton instance pointer, a land mine if any subsequent code should attempt to reference it. Use deleteSingleton() instead. ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the LLSingleton instance pointer pointing to an allocated-but-destroyed instance. Use deleteSingleton() instead.
2016-04-04merge with 4.0.3-releaseOz Linden
2015-11-10remove execute permission from many files that should not have itOz Linden
2015-09-15MAINT-5507: Remove llcurl, move constant values and untilities to llcorehttp libRider Linden
2015-09-14MAINT-5507: Removal of sdrpc client/serverRider Linden
MAINT-5507: removal of LLCurl::Easy, LLCurl::Multi LLCurl::Responder
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2011-09-06LLProxy code review fixes.Logan Dethrow
* Removed check_curl_code and check_curl_multi_code from the global namespace. * Added comments documenting which thread the public methods of LLProxy should be called from. * Corrected grammar in LLSingleton.h * Fixed a buffer scope problem in llpacketring.cpp.
2011-09-01LLProxy start of code review cleanup.Logan Dethrow
2011-08-08LLProxy cleanup.Logan Dethrow
Made the socks proxy start first in llstartup.cpp Moved initialization of the proxy to before the HTTP table fetch Added Doxygen comments to LLProxy methods. Removed call to applyProxySettings in llxmlrpctransaction.cpp since the ctor of LLCurlEasyRequest will apply the proxy settings.
2011-08-04LLProxy: Added another attempt to download gpu and feature tables after ↵Logan Dethrow
successfully setting up a proxy. Other minor changes: Clarified why we are using SOCKS5 as the "grid" argument to store proxy credentials. Added class wide logging to the LLProxy class.
2011-08-02LLProxy cleanup.Logan Dethrow
* Removed early returns in LLStartup::handleSocksProxy * Corrected some cases that would result in handleSocksProxy not being called again during login if settings changed * Allowed for short replies in tcp_handshake in LLProxy.cpp * Renamed LLProxy::isEnabled() to LLProxy::isSocksProxyEnabled() to clarify its use.
2011-08-02Proxy: Improved mutex usage in LLProxy. Introduced an LLAtomic member to ↵Logan Dethrow
track the status of the http proxy that can be checked without locking a mutex.
2011-07-29STORM-1112 Input sanitization of proxy options.Logan Dethrow
2011-07-21STORM-1112 Protected LLProxy members during cross-thread calls to ↵Logan Dethrow
LLProxy::applyProxySettings()
2011-07-19STORM-1112 Added LLProxy::applyProxySettings() to apply proxy settings to ↵Logan Dethrow
curl handles. Added call to that function everywhere curl handles are created in the viewer.
2011-07-13Code cleanup for the SOCKS 5 proxy viewer.Logan Dethrow
2011-07-13STORM-1112 Fixed network buffers that need to have space for the SOCKS proxy ↵Logan Dethrow
header.
2011-07-05STORM-1112 Fixed crash on quit. Other minor fixes:Logan Dethrow
* Reordered HTTP proxy choices in settings dialog * Now using setBlocking and setNonBlocking LLSocket methods during TCP handshakes. * Made those LLSocket methods available outside the class.
2011-06-28STORM-1112 More cleanup of SOCKS 5 proxy code.Logan Dethrow
Renamed llsocks5.cpp to llproxy.cpp.