summaryrefslogtreecommitdiff
path: root/indra/llcommon/llevents.h
AgeCommit message (Collapse)Author
2020-03-25DRTVWR-476: Eliminate static LLEventPump factory maps.Nat Goodspeed
Having a map from std::string to a factory function returning LLEventPump* is a cool idea, especially since you could statically populate such a map with string literals and little lambdas. Unfortunately, static initialization of any data is a bad idea when control can reach consuming code before that module's static data are constructed. Since LLEventPumps is already an LLSingleton, it's simple enough to make its map non-static and initialize it in the constructor. But another recent static factory-function map was introduced in llleaplistener.cpp to support the LLLeapListener::newpump() operation. That involves no LLSingletons. Introduce LLEventPumps::make(name, tweak, type) to instantiate an LLEventPump subclass of the specified type with specified (name, tweak) parameters. Instances returned by make() are owned by LLEventPumps, as with obtain(). Introduce LLEventPumps::BadType exception for when the type string isn't recognized. LLEventPumps::obtain() can then simply call make() when the specified instance name doesn't already exist. The configuration data used internally by obtain() becomes { string instance name, string subclass name }. Although this too is currently initialized in the LLEventPumps constructor, migrating it to a configuration file would now be far more straightforward than before. LLLeapListener::newpump(), too, can call LLEventPumps::make() with the caller-specified type string. This eliminates that static factory map. newpump() must catch BadType and report the error back to its invoker. Given that the LLEventPump subclass instances returned by make() are owned by LLEventPumps rather than LLLeapListener, there is no further need for the LLLeapListener::mEventPumps ptr_map, which was used only to manage lifetime. Also remove LLLeapListener's "killpump" operation since LLEventPumps provides no corresponding functionality.
2020-03-25DRTVWR-476: Kill LLEventQueue, per-frame LLEventPump::flush() calls.Nat Goodspeed
No one uses LLEventQueue to defer posted events until the next mainloop tick -- and with LLCoros moving to Boost.Fiber, cross-coroutine event posting works that way anyway, making LLEventQueue pretty unnecessary. The static RegisterFlush instance in llevents.cpp was used to call LLEventPumps::flush() once per mainloop tick, which in turn called flush() on every registered LLEventPump. But the only reason for that mechanism was to support LLEventQueue. In fact, when LLEventMailDrop overrode its flush() method for something quite different, it was startling to find that the new flush() override was being called once per frame -- which caused at least one fairly mysterious bug. Remove RegisterFlush. Both LLEventPumps::flush() and LLEventPump::flush() remain for now, though intended usage is unclear. Eliminating LLEventQueue means we must at least repurpose LLEventPumps::mQueueNames, a map intended to make LLEventPumps::obtain() instantiate an LLEventQueue rather than the default LLEventPump. Replace it with mFactories, a map from desired instance name to a callable returning LLEventPump*. New map initialization syntax plus lambda support allows us to populate that map at compile time with little lambdas returning the correct subclass instance. Similarly, LLLeapListener::newpump() used to check the ["type"] entry in the LLSD request specifically for "LLEventQueue". Introduce another such map in llleaplistener.cpp for potential future extensibility. Eliminate the LLEventQueue-specific test.
2020-03-25DRTVWR-476: Introduce LLEventMailDrop::discard() (instead of flush()).Nat Goodspeed
Overriding virtual LLEventPump::flush() for the semantic of discarding LLEventMailDrop's queued events turns out not to be such a great idea, because LLEventPumps::flush(), which calls every registered LLEventPump's flush() method, is called every mainloop tick. The first time we hit a use case in which we expected LLEventMailDrop to hold queued events across a mainloop tick, we were baffled that they were never delivered. Moving that logic to a separate method specific to LLEventMailDrop resolves that problem. Naming it discard() clarifies its intended functionality.
2020-03-25DRTVWR-476: Remove special case for listen(boost::bind(weak_ptr)).Nat Goodspeed
LLEventDetail::visit_and_connect() promised special treatment for the specific case when an LLEventPump::listen() listener was composed of (possibly nested) boost::bind() objects storing boost::weak_ptr values -- specifically boost::bind() rather than std::bind or lambdas, specifically boost::weak_ptr rather than std::weak_ptr. Outside of self-tests, it does not appear that anyone actually uses that support. There is good reason not to: it's a silent side effect of a complicated compile-time inspection that could be silently derailed by use of std::bind() or a lambda or a std::weak_ptr. Can you be sure you've engaged that promise? How? A more robust guarantee can be achieved by storing an LLTempBoundConnection in the transient object itself. When the object is destroyed, the listener is disconnected. Normal C++ rules around object destruction guarantee it. This idiom is widely used. There are a couple good reasons to remove the visit_and_connect() machinery: * boost::bind() and boost::weak_ptr do not constitute the wave of the future. Preferring those constructs to lambdas and std::weak_ptr penalizes new code, whether by silently failing or by discouraging use of modern idioms. * The visit_and_connect() machinery was always complicated, and apparently never very robust. Most of its promised features have been commented out over the years. Making the code base simpler, clearer and more maintainable is always a useful effect. LLEventDetail::visit_and_connect() was also used by the four LLNotificationChannelBase::connectMumble() methods. Streamline those as well. Of course, remove related test code.
2020-03-25DRTVWR-476: Remove llwrap(), LLListenerWrapper[Base] and support.Nat Goodspeed
The only usage of any of this was in test code.
2020-03-25SL-793: Add LLEventPumps::clear() method to disconnect all listeners.Nat Goodspeed
This is like the existing reset() method, except that reset() is specifically intended for shutdown: it disables every existing LLEventPump in such a way that it cannot be subsequently reused. (The original idea was to disconnect listeners in DLLs unloaded at shutdown.) clear() forcibly disconnects all existing listeners, but leaves LLEventPumps ready for reuse. This is useful (e.g.) for test programs to reset the state of LLEventPumps between individual test functions.
2019-05-14Mac buildfixAndreyL ProductEngine
2019-03-08SL-10702: When attempting a new voice connection, ensure that the voicePump ↵Rider Linden
mail drop does not have any outstanding events.
2018-09-27DRTVWR-474: Make LLEventMailDrop pass all saved events to listener.Nat Goodspeed
Previously, LLEventMailDrop would send only the first queued event to a newly-connected listener. If you wanted to flush all queued events, you'd have to "pump" the queue by repeatedly disconnecting and reconnecting -- with no good way to know when you'd caught up. The new behavior makes LLEventMailDrop resemble a multi-valued future: a rendezvous between producer and consumer that, once connected, pushes values rather than requiring them to be pulled (as with a simple queue) -- regardless of the relative order in which post() and listen() are called.
2017-03-13DRTVWR-418: Make LLEventPumps an LLHandleProvider for LLEventPump.Nat Goodspeed
LLEventPump's destructor was using LLEventPumps::instance() to unregister the LLEventPump instance from LLEventPumps. Evidently, though, there are lingering LLEventPump instances that persist even after the LLSingletonBase::deleteAll() call destroys the LLEventPumps LLSingleton instance. These were resurrecting LLEventPumps -- pointlessly, since a newly-resurrected LLEventPumps instance can have no knowledge of the LLEventPump instance! Unregistering is unnecessary! What we want is a reference we can bind into each LLEventPump instance that allows us to safely test whether the LLEventPumps instance still exists. LLHandle is exactly that. Make LLEventPumps an LLHandleProvider and bind its LLHandle in each LLEventPump's constructor; then the destructor can unregister only when LLEventPumps still exists.
2016-11-14Merged in lindenlab/viewer-cleanupAndreyL ProductEngine
2016-10-11MAINT-5232: Merge up to VLC viewer from viewer-releaseNat Goodspeed
2016-10-10Merged in lindenlab/viewer-releaseAndreyL ProductEngine
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-08-26MAINT-5011: Catch LLContinueError in LLStopWhenHandled::operator().Nat Goodspeed
This means that an exception derived from LLContinueError thrown in an LLEventPump listener won't prevent other listeners on the same LLEventPump from receiving that event.
2016-07-19MAINT-5011: Introduce LLException base class for viewer exceptions.Nat Goodspeed
This also introduces LLContinueError for exceptions which should interrupt some part of viewer processing (e.g. the current coroutine) but should attempt to let the viewer session proceed. Derive all existing viewer exception classes from LLException rather than from std::runtime_error or std::logic_error. Use BOOST_THROW_EXCEPTION() rather than plain 'throw' to enrich the thrown exception with source file, line number and containing function.
2016-06-23MAINT-6521: Allow anonymous connections to bypass the dependency and order ↵Rider Linden
tracking.
2016-05-06merge 4.0.4-release and MAINT-5974Oz Linden
2016-04-26MAINT-6336: Put the timeout upstream of the suspending pump and fire the ↵Rider Linden
timeout it. Also some cleanup on LLSD construction in vivox.
2016-04-04merge with 4.0.3-releaseOz Linden
2015-12-17MAINT-5977: Finish implementation of MailBox event pump type for guaranteed ↵Rider Linden
delivery
2015-12-17MAINT-5976: Adding MailDrop type event Queuerider
2015-12-04Initial changes for Vivox/Azumarill merge. Lots of temporary code and ↵Rider Linden
conditional compile switches. Begin switch from statemachine to coroutine.
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-07-30Summer cleaning - removed a lot of llcommon dependencies to speed up build timesRichard Linden
consolidated most indra-specific constants in llcommon under indra_constants.h fixed issues with operations on mixed unit types (implicit and explicit) made LL_INFOS() style macros variadic in order to subsume other logging methods such as ll_infos added optional tag output to error recorders
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2011-02-18Introduce and use new sendReply() function for LLEventAPI methods.Nat Goodspeed
Each LLEventAPI method that generates a reply needs to extract the name of the reply LLEventPump from the request, typically from a ["reply"] key, copy the ["reqid"] value from request to reply, locate the reply LLEventPump and send the enriched reply object. Encapsulate in sendReply() function before we proliferate doing all that by hand too many more times.
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-12-03Automated merge with ssh://hg.lindenlab.com/viewer/viewer-2-0/Nat Goodspeed
2009-12-03DEV-43463: swap visit_and_connect() overloads for Linux compilerNat Goodspeed
2009-12-03Fixed broken buildskolb
2009-11-30DEV-43463: Keep LLEventPump's LLStandardSignal alive during post()Nat Goodspeed
Replace LLEventPump's boost::scoped_ptr<LLStandardSignal> with boost::shared_ptr. Take a local stack copy of that shared_ptr in post() methods, and invoke the signal through that copy. This guards against scenario in which LLEventPump gets destroyed during signal invocation. (See Jira for details.) Re-enable Mani's test case that used to crash. Introduce ll_template_cast<> to allow a template function to recognize a parameter of a particular type. Introduce LLListenerWrapper mechanism to support wrapper objects for LLEventPump listeners. You instantiate an LLListenerWrapper subclass object inline in the listen() call (typically with llwrap<>), passing it the real listener, trusting it to forward the eventual call. Introduce prototypical LLCoutListener and LLLogListener subclasses for illustrative and diagnostic purposes. Test that LLLogListener doesn't block recognizing LLEventTrackable base class bound into wrapped listener.
2009-11-10Remove dangling LLEVENTS_LISTENER_ARITY controlNat Goodspeed
2009-11-03mergeLoren Shih
--HG-- branch : avatar-pipeline
2009-10-21Workaround for DEV-35406 lleventhost crash on shutdown.brad kittenbrink
The fix deletes all LLEventPumps boost::signal objects prior to unloading any dlls. reviewed by Nat.
2009-07-30Merged in viewer-2.0.0-3 changes up through r129050. Boost got clobbered so ↵brad kittenbrink
I'll need to rebuild that, plus a couple other minor clenaups.
2009-07-30Fixes to build on linux for DEV-35401.palmer@eniac54.lindenlab.com
Moves libllcommon.so to a staging dir for unit tests to work and gets rid of LL_COMMON_API in forward declarations
2009-07-16Merged work for DEV-2066 (and formerly QAR-1538) in Viewer 2.Mark Palange
merged all changes, post copy, from the following branches: linden/brachnes/enable-o-v user/cg/qar-1538 user/mani/viewer2-enable-o-v
2009-07-01Fixups for windows llcommon dll linkage errors that got dropped in the merge ↵brad kittenbrink
up to viewer-2.0.0-3
2009-06-23Incomplete attempt to clean up Mercurial branch buildNat Goodspeed
2009-06-21merge -r 122421-124917 viewer-2.0.0-2 -> viewer-2.0.0-3Steven Bennetts
ignore-dead-branch
2009-06-04Merge of QAR-1383 event-system-7 into trunk.Brad Kittenbrink
svn merge -r 121797:121853 svn+ssh://svn.lindenlab.com/svn/linden/branches/merge-event-system-7