| Age | Commit message (Collapse) | Author |
|---|
|
* Integrate Velopack installer and update framework
* Add Velopack update support for macOS and VVM integration
* Update Velopack version and dependencies
* Improve Velopack packaging for macOS
* #5346 Uninstall older non-velopack viewer (#5363)
* #5335 Fix silent uninstall asking about registry
* #5346 Uninstall older non-velopack viewer
* Use runtime viewer exe name, handle Velopack URL
* Velopack download failure diagnostic (#5520)
* Velopack download failure diagnostic
* Fix up velopack downloading updates. Handle updates internally then hand them off to velopack. (#5524)
* More velopack changes. Should download updates properly now.
* Don't include NSI files
* Restore optional updates, refine viewer restart behavior. (#5527)
* Add support for optional updates.
* Don't restart the viewer after the update unless it was optional.
* Setup UpdaterServiceSetting with velopack properly.
* Refine the restart behavior a bit - readd the old "the viewer must update" UX.
* If the update is still downloading, close should just reopen the downloading dialog.
---------
Co-authored-by: Jonathan "Geenz" Goodman <geenz@lindenlab.com>
* Remove SLVersionChecker from the viewer with velopack. (#5528)
* Remove SLVersionChecker updater integration
* Ensure that the portable install has the correct version number.
* Don't produce shortcuts with VPK - we do this with our post install.
* Bump viewer version from 26.1.0 to 26.1.1
* Potential fix for uninstaller not being functional.
* Fix for UpdaterServiceSetting being ignored.
* Filter for release channel when generating shortcuts.
* Add some more logging for icons on Windows builds.
* More VPK logging.
* Move velopack packaging in CI to the sign and package step.
* Enable velopack downgrade and skip older updates
* Move the version required checking into velopack's checks.
* Potential fix for downgrade prompts.
* Make sure our macOS flow mirrors Windows.
* Make sure to use the dev version of the mac sign and package.
* p#553 Only one of two uninstallers displayed
* #5346 Don't force user to shutdown velopack build for NSIS uninstall
* #5346 Ignore option for the uninstall dialog
* #5346 Fix early exit crash
* #5346 Properly reset version flag.
* Add some autodetect logic on macOS.
* p#564 Clear legacy links
* p#553 Handle uninstall records
* p#549 Permit testing release notes on a test build
* p#564 Remake nsis to velopack update flow
* p#564 Remake nsis to velopack update flow #2
* p#564 Fix incorrect value type
* p#553 Clear velopack's own registry entry in favor of a custom one
* #5346 Resolve duplicated window class name
* Bump to 2.1.0 of sign and package.
---------
Co-authored-by: Andrey Kleshchev <117672381+akleshchev@users.noreply.github.com>
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llvoavatar.cpp
|
|
|
|
|
|
# Conflicts:
# indra/llcommon/lldate.h
# indra/newview/llappviewer.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llmaterialeditor.cpp
# indra/newview/llviewerparceloverlay.cpp
# indra/newview/llvoavatar.cpp
|
|
|
|
|
|
We need those to know about problems.
|
|
LF, and trim trailing whitespaces as needed
|
|
|
|
Rather than continuing to propagate try/catch (Closed)
(aka LLThreadSafeQueueInterrupt) constructs through the code base, make
WorkQueueBase::post() return bool indicating success (i.e. ! isClosed()).
This obviates postIfOpen(), which no one was using anyway.
In effect, postIfOpen() is renamed post(), bypassing the exception when
isClosed().
Review existing try/catch blocks of that sort, changing to test for post()
returning false.
|
|
For work queues that don't need timestamped tasks, eliminate the overhead of a
priority queue ordered by timestamp. Timestamped task support moves to
WorkSchedule. WorkQueue is a simpler queue that just waits for work.
Both WorkQueue and WorkSchedule can be accessed via new WorkQueueBase API. Of
course the WorkQueueBase API doesn't deal with timestamps, but a WorkSchedule
can be accessed directly to post timestamped tasks and then handled normally
(e.g. by ThreadPool) to run them.
Most ThreadPool functionality migrates to new ThreadPoolBase class, with
template subclass ThreadPoolUsing<WorkQueue> or ThreadPoolUsing<WorkSchedule>
depending on need. ThreadPool is now an alias for ThreadPoolUsing<WorkQueue>.
Importantly, ThreadPoolUsing::getQueue() delivers a reference to the specific
queue subclass type, so you can post timestamped tasks on a queue retrieved
from ThreadPoolUsing<WorkSchedule>::getQueue().
Since ThreadPool is no longer a simple class but an alias for a particular
template specialization, introduce threadpool_fwd.h to forward-declare it.
Recast workqueue_test.cpp to exercise WorkSchedule, since some of the tests
are time-based. A future todo would be to exercise each applicable test with
both WorkQueue and WorkSchedule.
|
|
|
|
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.
|
|
runFor(interval) and runUntil(timestamp) are intended, and documented, to run
*no longer than* the specified time. Instead, the initial implementation
always waited the full specified time, hoping for work to arrive. Fix that:
once we clear work that's already pending, return right away.
|
|
|
|
|
|
This reverts commit 5188a26a8521251dda07ac0140bb129f28417e49, reversing
changes made to 819088563e13f1d75e048311fbaf0df4a79b7e19.
|
|
We want to skip calling PostMessage() to bump the window thread out of
GetMessage() in any frame with no work functions pending for that thread. That
test depends on being able to sense the size() of the queue. Having converted
to WorkQueue, we need that queue to support size().
|
|
Give ThreadPool and WorkQueue the ability to override default
ThreadSafeSchedule capacity.
Instantiate "mainloop" WorkQueue and "General" ThreadPool with very large
capacity because we never want to have to block trying to push to either.
|
|
|
|
In addition to the name making the blocking explicit, we changed the
signature: instead of specifying a target WorkQueue on which to run,
waitForResult() runs the passed callable on its own WorkQueue.
Why is that? Because, unlike postTo(), we do not require a handshake between
two different WorkQueues. postTo() allows running arbitrary callback code,
setting variables or whatever, on the originating WorkQueue (presumably on the
originating thread). waitForResult() synchronizes using Promise/Future, which
are explicitly designed for cross-thread communication. We need not call
set_value() on the originating thread, so we don't need a postTo() callback
lambda.
|
|
The idea is that you can call runOn(target, callable) from a (non-default)
coroutine and block that coroutine until the result becomes available.
As a safety check, we forbid calling runOn() from a thread's default
coroutine, assuming that a given thread's default coroutine is the one
servicing the relevant WorkQueue.
|
|
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.
|
|
optimization bugs.
|
|
Also make workqueue_test.cpp more robust.
|
|
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.
|
