summaryrefslogtreecommitdiff
path: root/indra/llcommon/tests/workqueue_test.cpp
AgeCommit message (Collapse)Author
2024-04-29#824 Process source files in bulk: replace tabs with spaces, convert CRLF to ↵Andrey Lihatskiy
LF, and trim trailing whitespaces as needed
2023-10-25Merge remote-tracking branch 'origin/main' into DRTVWR-559Brad Linden
2023-06-05SL-18837: Bump the granularity of WorkQueue timing tests.Nat Goodspeed
On a low-powered GitHub Mac runner, the system doesn't wake up as soon as it should, and we get spurious "too late" errors. Try a bigger time increment.
2022-12-09SL-18809: Add WorkSchedule; remove timestamps from WorkQueue.Nat Goodspeed
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.
2021-11-24SL-16094: Fix WorkQueue test for correct behavior of runFor().Nat Goodspeed
Turns out that one of our WorkQueue integration tests was relying on the incorrect runFor() behavior that we just fixed, so the test broke. Now that runFor() doesn't wait around for work to be posted, use an explicit wait loop instead. To support this, add LLCond::get(functor), where functor must accept a const reference to the stored data. This new get() returns whatever the functor returns, allowing a caller to peek at the stored data. Also use universal references for all remaining LLCond functor arguments.
2021-11-24DRTVWR-546, SL-16220, SL-16094: Undo previous glthread branch revert.Nat Goodspeed
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.
2021-11-15Revert "SL-16220: Merge branch 'origin/DRTVWR-546' into glthread"Dave Houlton
This reverts commit 5188a26a8521251dda07ac0140bb129f28417e49, reversing changes made to 819088563e13f1d75e048311fbaf0df4a79b7e19.
2021-10-27SL-16220: Add tests for WorkQueue::waitForResult(), void & non-void.Nat Goodspeed
2021-10-25SL-16220: Specialize WorkQueue for callable with void return.Nat Goodspeed
Add a test exercising this feature.
2021-10-07SL-16024: Defend against two threads making "anonymous" WorkQueues.Nat Goodspeed
Also make workqueue_test.cpp more robust.
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.