| Age | Commit message (Collapse) | Author |
|---|
|
|
|
code in PCH (#2361)
|
|
Remove documented `LLEventPump` support for `LLEventTrackable`. That claimed
support was always a little bit magical/fragile. IF:
* a class included `LLEventTrackable` as a base class AND
* an instance of that class was managed by `boost::shared_ptr` AND
* you passed one of that class's methods and the `boost::shared_ptr`
specifically to `boost::bind()` AND
* the resulting `boost::bind()` object was passed into `LLEventPump::listen()`
THEN the promise was that on destruction of that object, that listener would
automatically be disconnected -- instead of leaving a dangling pointer bound
into the `LLEventPump`, causing a crash on the next `LLEventPump::post()` call.
The only existing code in the viewer code base that exercised `LLEventTrackable`
functionality was in test programs. When the viewer calls `LLEventPump::listen()`,
it typically stores the resulting connection object in an `LLTempBoundListener`
variable, which guarantees disconnection on destruction of that variable.
The fact that `LLEventTrackable` support is specific to `boost::bind()`, that it
silently fails to keep its promise with `std::bind()` or a lambda or any other
form of C++ callable, makes it untrustworthy for new code.
Note that the code base still uses `boost::signals2::trackable` for other
`boost::signals2::signal` instances not associated with `LLEventPump`. We are
not changing those at this time.
|
|
LF, and trim trailing whitespaces as needed
|
|
|
|
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.
|
|
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.
|
|
The only usage of any of this was in test code.
|
|
Use them in place of awkward try/catch test boilerplate.
|
|
|
|
lltut.h declares a number of ensure_equals() overloads for various data types,
notably the types supported by LLSD. We expect these to be called by tut code.
But the tut code in question is in a template in tut.hpp -- which was
#included BEFORE the overloads were declared. Previous C++ compilers have
evidently made multiple passes, collecting the relevant overloads before
attempting to compile the template bodies. clang does not, complaining that
the overloads must be declared before the tut.hpp template code that
references them. Reordering parts of lltut.h seems to address that problem.
For similar reasons, test programs that use StringVec.h and its operator<<()
must #include StringVec.h before lltut.h.
Add ensure_equals(const std::string&, const LLSD::Binary&, const LLSD::Binary&)
overload. The sloppy mix of (const char*, ...) and (const std::string&, ...)
overloads bothers me, since for many of those ... types we seem to have to
duplicate them.
|
|
|
|
|
|
In the course of re-enabling the indra/test tests last year, Log generalized a
workaround I'd introduced in llsdmessage_test.cpp. In Linux viewer land, a
test program trying to catch an expected exception can't seem to catch it by
its specific class (across the libllcommon.so boundary), but must instead
catch std::runtime_error and validate the typeid().name() string. Log added a
macro for this idiom in llevents_tut.cpp. Generalize that macro further for
normal-case processing as well, move it to a header file of its own and use it
in all known places -- plus the new exception-catching tests in
llprocess_test.cpp.
|
|
llevents_tut.cpp.
|
|
pass on a lenny build
machine.
|
|
|
|
failures.
|
|
|
|
CMakeLists.txt.
|
|
|
|
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.
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/login-api/login-api-2 svn+ssh://svn.lindenlab.com/svn/linden/branches/login-api/login-api-3
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/event-system/event-system-7 svn+ssh://svn.lindenlab.com/svn/linden/branches/event-system/event-system-8
|
