summaryrefslogtreecommitdiff
path: root/indra/llcommon/threadsafeschedule.h
AgeCommit message (Collapse)Author
2023-02-13Fix up a couple of tiny merge conflicts after a merge with mainCallum Prentice
2022-11-03DRTVWR-575: Fix llcommon assumptions that size_t fits in 4 bytes.Nat Goodspeed
It's a little distressing how often we have historically coded S32 or U32 to pass a length or index. There are more such assumptions in other viewer subdirectories, but this is a start.
2022-07-28GCC11.1 warning: moving a local object in a return statement prevents copy ↵ZiRee
elision [-Werror=pessimizing-move]
2022-01-14SL-16606: Add profiler category THREADPtolemy
2021-11-22SL-16094 More profile hooks for threading code, remove redundant ↵Runitai Linden
wglCreateContextAttribs call
2021-10-07SL-16024: Add LL::WorkQueue for passing work items between threads.Nat Goodspeed
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.
2021-10-06SL-16024: Work around VS bug regarding base-class enum.Nat Goodspeed
2021-10-06SL-16024: Fix ThreadSafeSchedule::tryPopFor(), tryPopUntil().Nat Goodspeed
ThreadSafeSchedule::tryPopUntil() (and therefore tryPopFor()) was simply delegating to LLThreadSafeQueue::tryPopUntil(), with an adjusted timeout since we want to wake up as soon as the head item, if any, becomes ready. But then we have to loop back to retry the pop to actually deal with that head item. In addition, ThreadSafeSchedule::popWithTime() was spinning rather than properly blocking on a timed condition variable. Fixed.
2021-10-05SL-16024: Add ThreadSafeSchedule, a timestamped LLThreadSafeQueue.Nat Goodspeed
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.