| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Otherwise we fall into the trap of destroying a joinable std::thread, which
calls std::terminate() and hence our crash-on-terminate() handler.
The previous ~ThreadPool() logic only joined threads if the queue wasn't
already closed, but evidently we can reach the destructor with the queue
closed but the threads not yet joined.
Fixes #1534.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 82d713782529074b03720833038cb0df2b8bcffd)
|
|
|
|
|
|
|
|
|
|
following promotion of secondlife/viewer #705: Maintenance X
|
|
Maintenance X
|
|
|
|
Instead of making LLEventPumps an LLHandleProvider, and storing an
LLHandle<LLEventPumps> in each LLEventPump instance, just make ~LLEventPump()
query LLEventPumps::instanceExists() before calling instance().
|
|
Rename LL::Timers::scheduleRepeating() to scheduleEvery().
|
|
(cherry picked from commit dc0b3aed4782e4e4835fd6b9d59d1d70b78be4a7)
|
|
|
|
|
|
In its GitHub PR build, the nat/cleanup-timers branch hit a (rare!)
mathmisc_test failure. But since the test failure didn't report any of the
randomly generated values that led to the failure, all we can do is shrug and
rerun. Pull in the changeset from that branch that adds mathmisc_test
reporting in case of another such failure.
|
|
|
|
|
|
|
|
|
|
|
|
In the previous design, the tick() method ran each task exactly once.
doPeriodically() was implemented by posting a functor that would, after
calling the specified callable, repost itself at (timestamp + interval).
The trouble with that design is that it required (interval > 0). A nonpositive
interval would result in looping over any timers with nonpositive repetition
intervals without ever returning from the tick() method.
To avoid that, doPeriodically() contained an llassert(interval > 0).
Unfortunately the viewer failed that constraint immediately at login, leading
to the suspicion that eliminating every such usage might require a protracted
search.
Lifting that restriction required a redesign. Now the priority queue stores a
callable returning bool, and the tick() method itself contains the logic to
repost a recurring task -- but defers doing so until after it stops looping
over ready tasks, ensuring that a task with a nonpositive interval will at
least wait until the following tick() call.
This simplifies not only doPeriodically(), but also doAtTime(). The previous
split of doAtTime() into doAtTime1() and doAtTime2() was only to accommodate
the needs of the Periodic functor class. Ditch Periodic.
Per feedback from NickyD, rename doAtTime() to scheduleAt(), which wraps its
passed nullary callable into a callable that unconditionally returns true (so
tick() will run it only once).
Rename the doAfterInterval() method to scheduleAfter(), which similarly wraps
its nullary callable. However, the legacy doAfterInterval() free function
remains. scheduleAfter() also loses its llassert(seconds > 0).
Rename the doPeriodically() method to scheduleRepeating(). However, the legacy
doPeriodically() free function remains.
Add internal scheduleAtRepeating(), whose role is to accept both a specific
timestamp and a repetition interval (which might be ignored, depending on the
callable). scheduleAtRepeating() now contains the real logic to add a task.
Rename getRemaining() to timeUntilCall(), hopefully resolving the question of
"remaining what?"
Expand the std::pair metadata stored in Timers's auxiliary unordered_map to a
Metadata struct containing the repetition interval plus two bools to mediate
deferred cancel() processing. Rename HandleMap to MetaMap, mHandles to mMeta.
Defend against the case when cancel(handle) is reached during the call to that
handle's callable. Meta::mRunning is set for the duration of that call. When
cancel() sees mRunning, instead of immediately deleting map entries, it sets
mCancel. Upon return from a task's callable, tick() notices mCancel and
behaves as if the callable returned true to stop the series of calls.
To guarantee that mRunning doesn't inadvertently remain set even in the case
of an exception, introduce local RAII class TempSet whose constructor accepts
a non-const variable reference and a desired value. The constructor captures
the current value and sets the desired value; the destructor restores the
previous value.
Defend against exception in a task's callable, and stop calling that task. Use
LOG_UNHANDLED_EXCEPTION() to report it.
|
|
|
|
|
|
If there is exactly one doPeriodically() entry on LLLater, the mQueue entry is
deleted before Periodic::operator()() is called. If Periodic's callable
returns false, it reinstates itself on mQueue for a future time. That's okay,
because the test for mQueue.empty(), and the consequent disconnect from
LLCallbackList, happens only after that Periodic call returns.
But at the moment Periodic reinstates itself on mQueue, mQueue happens to be
empty. That alerts doAtTime2() to register itself on LLCallbackList -- even
though at that moment it's already registered.
Semantically that's okay because assigning to the LLLater's
LLCallbackList::temp_handle_t should implicitly disconnect the previous
connection. But it's pointless to create a new connection and disconnect the
old one every time we call that lone Periodic.
Add a test for mLive.connected(); that way if we already have an
LLCallbackList connection, we retain it instead of replacing it with a new
one.
|
|
LLAvatarListUpdater is an LLEventTimer subclass meant to be a base class of
still other subclasses. One would presume that every one of them should
override tick(), since LLAvatarListUpdater::tick() is a no-op that simply asks
to be called again. But making it abstract (=0) produces errors since at least
one subclass does not define its own tick() method. This seems less than
useful, since the specific tick() method is the whole point of deriving from
LLEventTimer, but oh well.
|
|
Instead of maintaining a whole separate unordered_map to look up target times,
make room in the HandleMap entry for the target time. There's still
circularity, but the split into doAtTime1() and doAtTime2() resolves it: since
doAtTime2() accepts the mHandles iterator created by doAtTime1(), doAtTime2()
can simply store the new mQueue handle_type into the appropriate slot.
Also sprinkle in a few more override keywords for consistency.
|
