| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Reverting a merge is sticky: it tells git you never want to see that branch
again. Merging the DRTVWR-546 branch, which contained the revert, into the
glthread branch undid much of the development work on that branch. To restore
it we must revert the revert.
This reverts commit 029b41c0419e975bbb28454538b46dc69ce5d2ba.
|
|
|
|
This reverts commit 5188a26a8521251dda07ac0140bb129f28417e49, reversing
changes made to 819088563e13f1d75e048311fbaf0df4a79b7e19.
|
|
|
|
ThreadPool bundles a WorkQueue with the specified number of worker threads to
service it. Each ThreadPool has a name that can be used to locate its
WorkQueue.
Each worker thread calls WorkQueue::runUntilClose().
ThreadPool listens on the "LLApp" LLEventPump for shutdown notification. On
receiving that, it closes its WorkQueue and then join()s each of its worker
threads for orderly shutdown.
Add a settings.xml entry "ThreadPoolSizes", the first LLSD-valued settings
entry to expect a map: pool name->size. The expectation is that usually code
instantiating a particular ThreadPool will have a default size in mind, but it
should check "ThreadPoolSizes" for a user override.
Make idle_startup()'s STATE_SEED_CAP_GRANTED state instantiate a "General"
ThreadPool. This is function-static for lazy initialization.
Eliminate LLMainLoopRepeater, which is completely unreferenced. Any potential
future use cases are better addressed by posting to the main loop's WorkQueue.
Eliminate llappviewer.cpp's private LLDeferredTaskList class, which
implemented LLAppViewer::addOnIdleCallback(). Make addOnIdleCallback() post
work to the main loop's WorkQueue instead.
|
|
|
|
|
|
A typical WorkQueue has a string name, which can be used to find it to post
work to it. "Work" is a nullary callable.
WorkQueue is a multi-producer, multi-consumer thread-safe queue: multiple
threads can service the WorkQueue, multiple threads can post work to it.
Work can be scheduled in the future by submitting with a timestamp. In
addition, a given work item can be scheduled to run on a recurring basis.
A requesting thread servicing a WorkQueue of its own, such as the viewer's
main thread, can submit work to another WorkQueue along with a callback to be
passed the result (of arbitrary type) of the first work item. The callback is
posted to the originating WorkQueue, permitting safe data exchange between
participating threads.
Methods are provided for different kinds of servicing threads. runUntilClose()
is useful for a simple worker thread. runFor(duration) devotes no more than a
specified time slice to that WorkQueue, e.g. for use by the main thread.
|
|
ThreadSafeSchedule orders its items by timestamp, which can be passed either
implicitly or explicitly. The timestamp specifies earliest delivery time: an
item cannot be popped until that time.
Add initial tests.
Tweak the LLThreadSafeQueue base class to support ThreadSafeSchedule:
introduce virtual canPop() method to report whether the current head item is
available to pop. The base class unconditionally says yes, ThreadSafeSchedule
says it depends on whether its timestamp is still in the future.
This replaces the protected pop_() overload accepting a predicate. Rather than
explicitly passing a predicate through a couple levels of function call, use
canPop() at the level it matters. Runtime behavior that varies depending on
an object's leaf class is what virtual functions were invented for.
Give pop_() a three-state enum return so pop() can distinguish between "closed
and empty" (throws exception) versus "closed, not yet drained because we're
not yet ready to pop the head item" (waits).
Also break out protected tryPopUntil_() method, the body logic of
tryPopUntil(). The public method locks the data structure, the protected
method requires that its caller has already done so.
Add chrono.h with a more full-featured LL::time_point_cast() function than the
one found in <chrono>, which only converts between time_point durations, not
between time_points based on different clocks.
|
|
These functions allow prepending or removing an item at the left end of an
arbitrary tuple -- for instance, to add a sequence key to a caller's data,
then remove it again when delivering the original tuple.
|
|
to tracy.lib
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# build.sh
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewermacosx.cpp
# indra/newview/llappviewerwin32.h
# indra/newview/viewer_manifest.py
# indra/win_crash_logger/llcrashloggerwindows.cpp
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llappcorehttp.cpp
# indra/newview/llappcorehttp.h
|
|
Bring in Oz's tweaks to the way BugSplat is engaged and tested, plus a few
other miscellaneous goodies.
|
|
# Conflicts:
# indra/newview/lltoolpie.cpp
|
|
# Conflicts:
# autobuild.xml
|
|
|
|
|
|
|
|
|
|
|
|
Now that we have the Sync class to help construct unit tests that move forward
in a deterministic stepwise order, we can build suitable unit tests for
LLMainThreadTask.
|
|
|
|
The only usage of any of this was in test code.
|
|
|
|
Longtime fans will remember that the "dcoroutine" library is a Google Summer
of Code project by Giovanni P. Deretta. He originally called it
"Boost.Coroutine," and we originally added it to our 3p-boost autobuild
package as such. But when the official Boost.Coroutine library came along
(with a very different API), and we still needed the API of the GSoC project,
we renamed the unofficial one "dcoroutine" to allow coexistence.
The "dcoroutine" library had an internal low-level API more or less analogous
to Boost.Context. We later introduced an implementation of that internal API
based on Boost.Context, a step towards eliminating the GSoC code in favor of
official, supported Boost code.
However, recent versions of Boost.Context no longer support the API on which
we built the shim for "dcoroutine." We started down the path of reimplementing
that shim using the current Boost.Context API -- then realized that it's time
to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
which we've been itching to do for literally years now.
Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
the differences between "dcoroutine" and Boost.Fiber.
The one feature Boost.Fiber does not provide is the ability to forcibly
terminate some other fiber. Accordingly, disable LLCoros::kill() and
LLCoprocedureManager::shutdown(). The only known shutdown() call was in
LLCoprocedurePool's destructor.
We also took the opportunity to remove postAndSuspend2() and its associated
machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
when the Responder pattern was king, and we assumed we'd want to listen on one
LLEventPump with the success handler and on another with the error handler. We
have never actually used that in practice. Remove associated tests, of course.
There is one other semantic difference that necessitates patching a number of
tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
ready to resume next time the scheduler gets around to it. To observe the test
side effects, we've inserted a number of llcoro::suspend() calls -- also in
the main loop.
For a long time we retained a single unit test exercising the raw "dcoroutine"
API. Remove that.
Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
that, remove the hack.
In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
tracking in place of llcoro::get_id().
In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
don't actually use the Boost.Coroutine for anything (though there exist
plausible use cases).
|
|
If already running on the main thread, LLMaintThreadTask simply runs the work
inline. Otherwise it queues it for the main thread using LLEventTimer, using
std::future to retrieve the result.
|
|
The pattern of requiring a lock to permit *any* access to a static instance of
something seems generally useful. Break out lockstatic.h; recast
LLInstanceTracker to use it.
Moving LockStatic to an external template class instead of a nested class in
LLInstanceTrackerBase leaves LLInstanceTrackerBase pretty empty. Get rid of it.
And *that* means we can move the definition of the StaticData used by each
LLInstanceTracker specialization into the class itself, rather than having to
define it beforehand in namespace LLInstanceTrackerStuff.
|
|
|
|
|
|
|
|
|
|
|
|
Define the CMake cache variable, with empty string as its default.
Make build.sh pass the BUGSPLAT_DB environment variable as a CMake
command-line variable assignment.
Change CMake 'if (DEFINED ENV{BUGSPLAT_DB})' to plain 'if (BUGSPLAT_DB)'.
Make CMake pass new --bugsplat switch to every one of SIX different
invocations of viewer_manifest.py.
Give llmanifest.main() function an argument to allow supplementing the base
set of command-line switches with additional application-specific switches.
In viewer_manifest.py, define new --bugsplat command-line switch and pass to
llmanifest.main(). Instead of consulting os.environ['BUGSPLAT_DB'], consult
self.args['bugsplat'].
|
|
Pass LL_BUGSPLAT into llapp.cpp compile to be able to detect that.
|
|
codes from core.
|
|
|
|
For some reason there wasn't an entry in indra/llcommon/CMakeLists.txt to run
the tests in indra/llcommon/tests/lleventfilter_test.cpp. It seems likely that
at some point it existed, since all previous tests built and ran successfully.
In any case, (re-)add lleventfilter_test.cpp to the set of llcommon tests.
Also alphabetize them to make it easier to find a particular test invocation.
Also add new tests for LLEventThrottle.
To support this, refactor the concrete LLEventThrottle class into
LLEventThrottleBase containing all the tricky logic, with pure virtual
methods for access to LLTimer and LLEventTimeout, and an LLEventThrottle
subclass containing the LLTimer and LLEventTimeout instances and corresponding
implementations of the new pure virtual methods.
That permits us to introduce TestEventThrottle, an alternate subclass with
dummy implementations of the methods related to LLTimer and LLEventTimeout. In
particular, we can explicitly advance simulated realtime to simulate
particular LLTimer and LLEventTimeout behaviors.
Finally, introduce Concat, a test LLEventPump listener class whose function is
to concatenate received string event data into a composite string so we can
readily test for particular sequences of events.
|
|
|
|
|
|
DRTVWR-412 Bento (avatar skeleton extensions)
|
|
The present CMake logic wants to pass FIXED:NO to the linker for 64-bit
builds, which on the face of it seems like a Good Thing: it permits code to be
relocated in memory, preventing collisions if two libraries happen to want to
load into overlapping address ranges.
However the way it's being specified is wrong and harmful. Passing /FIXED:NO
to the compiler command line engages /FI (Forced Include!) of a nonexistent
file XED:NO -- producing lots of baffling fatal compile errors.
Thanks Callum for diagnosing this!
|
|
autobuild 1.1 now supports expanding $variables within a config file --
support that was explicitly added to address this very problem. So now the
windows platform in autobuild.xml uses $AUTOBUILD_ADDRSIZE,
$AUTOBUILD_WIN_VSPLATFORM and $AUTOBUILD_WIN_CMAKE_GEN, which should handle
most of the deltas between the windows platform and windows64.
This permits removing the windows64 platform definition from autobuild.xml.
The one remaining delta between the windows64 and windows platform definitions
was -DLL_64BIT_BUILD=TRUE. But we can handle that instead by checking
ADDRESS_SIZE. Change all existing references to WORD_SIZE to ADDRESS_SIZE
instead, and set ADDRESS_SIZE to $AUTOBUILD_ADDRSIZE. Change the one existing
LL_64BIT_BUILD reference to test (ADDRESS_SIZE EQUAL 64) instead.
|
|
|
|
|
|
|
|
We need LLSingleton machinery to be able to reference get_id() without also
depending on all the rest of LLCoros -- since LLCoros isa LLSingleton.
|
