| Age | Commit message (Collapse) | Author |
|---|
|
The observed crash was due to sharing a stateful global resource (the global
LLMessageSystem instance) between different tasks. Specifically, a coroutine
sets its mMessageReader one way, expecting that value to persist until it's
done with message parsing, but another coroutine sneaks in at a suspension
point and sets it differently.
Introduce LockMessageReader and LockMessageChecker classes, which must be
instantiated by a consumer of the resource. The constructor of each locks a
coroutine-aware mutex, so that for the lifetime of the lock object no other
coroutine can instantiate another.
Refactor the code so that LLMessageSystem::mMessageReader can only be modified
by LockMessageReader, not by direct assignment. mMessageReader is now an
instance of LLMessageReaderPointer, which supports dereferencing and
comparison but not assignment. Only LockMessageReader can change its value.
LockMessageReader addresses the use case in which the specific mMessageReader
value need only persist for the duration of a single method call. Add an
instance in LLMessageHandlerBridge::post().
LockMessageChecker is a subclass of LockMessageReader: both lock the same
mutex. LockMessageChecker addresses the use case in which the specific
mMessageReader value must persist across multiple method calls. Modify the
methods in question to require a LockMessageChecker instance. Provide
LockMessageChecker forwarding methods to facilitate calling the underlying
LLMessageSystem methods via the LockMessageChecker instance.
Add LockMessageChecker instances to LLAppViewer::idleNetwork(), a couple cases
in idle_startup() and LLMessageSystem::establishBidirectionalTrust().
|
|
|
|
following promotion of DRTVWR-500
|
|
|
|
|
|
# Conflicts:
# indra/newview/pipeline.cpp
|
|
following promotion of DRTVWR-440
|
|
|
|
|
|
|
|
water Fresnel
|
|
|
|
|
|
|
|
|
|
|
|
Fix light falloff being corrupted when editing value via build floater spinner
Approved-by: Dave Houlton
|
|
Fix editing light color corrupting intensity and color values
Approved-by: Dave Houlton
|
|
|
|
|
|
|
|
|
|
SL-12902 Better fix for light color values in color swatch not matching light color values inworld.
|
|
light color values inworld.
|
|
|
|
|
|
WRT light color values.
|
|
|
|
The new LLCoros::Stop exception is intended to terminate long-lived coroutines
-- not interrupt mainstream shutdown processing. Only throw it on an
explicitly-launched coroutine.
Make LLCoros::getName() (used by the above test) static. As with other LLCoros
methods, it might be called after the LLCoros LLSingleton instance has been
deleted. Requiring the caller to call instance() implies a possible need to
also call wasDeleted(). Encapsulate that nuance into a static method instead.
|
|
|
|
Earlier versions of macOS manifested frustrating problems in finishing the
built package. Those build steps seem to have been behaving better for a few
years now. Eliminate (what we fervently hope has become) a bit of ancient cruft.
|
|
That way, if there's a problem, a developer can rerun the same command.
|
|
However, this is not the right moment to perform that refactoring.
|
|
|
|
|
|
|
|
Also forget obsolete references to VS 2010 runtime DLLs.
|
|
|
|
LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late
as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has
already called LLSingletonBase::deleteAll(), destroying the LLWatchdog
LLSingleton instance.
But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls
stop(), and stop() tries to remove that instance from LLWatchdog, thus
inadvertently resurrecting the deleted LLWatchdog. Which is pointless because
the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance
trying to remove itself.
Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has
already been deleted.
|
|
Add ndof_dump_list() call, to enumerate available devices, when
ndof_init_first() returns failure.
Add "joystick" tags to existing LL_INFOS() (etc.) calls in
llviewerjoystick.cpp to make it easier to enable and disable such log
messages.
Add a specialized operator<<() function to log the contents of an NDOF_Device
struct. Add a couple LL_DEBUGS() calls for more visibility into library
operations.
|
|
Instead of heap-allocating a CoroData instance per coroutine, storing the
pointer in a ptr_map and deleting it from the ptr_map once the
fiber_specific_ptr for that coroutine is cleaned up -- just declare a stack
instance on the top-level stack frame, the simplest C++ lifespan management.
Derive CoroData from LLInstanceTracker to detect potential name collisions and
to enumerate instances.
Continue registering each coroutine's CoroData instance in our
fiber_specific_ptr, but use a no-op deleter function.
Make ~LLCoros() directly pump the fiber scheduler a few times, instead of
having a special "LLApp" listener.
|
|
which performs "by hand" the same sequence of calls found in stepFrame().
Why not simply call stepFrame()? Hysterical reasons?
|
|
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.
|
|
The LLEventMailDrop used to communicate with the Vivox coroutine is a member
of LLVivoxVoiceClient. We don't need to keep looking it up by its string name
in LLEventPumps.
|
|
|
|
|
|
|
|
Poller.
|
|
|
|
|
