summaryrefslogtreecommitdiff
path: root/indra/llcommon/threadpool.h
AgeCommit message (Collapse)Author
2024-08-28Ditch trailing spaces.Nat Goodspeed
2024-04-17Reintroduce LLCoros::killreq() to request killing a named coroutine.Nat Goodspeed
Make LLCoros constructor echo "LLApp" status-change events on new "LLCoros" event pump. Rename LLCoros::kill() to killreq() because this operation only registers a request for the named coroutine to terminate next time it calls checkStop(). Add a new CoroData member to record the name of the coroutine requesting termination. killreq() sets that and also posts "killreq" to "LLCoros". Add an optional final-cleanup callback to LLCoros::checkStop(). Make checkStop() check for a pending killreq() request as well as viewer termination. Introduce new LLCoros::Killed exception for that case. Introduce LLCoros::getStopListener(), with two overloads, to encapsulate some of the messy logic to listen (perhaps temporarily) for viewer shutdown. Both overloads are for use by code at the source end of a queue or promise or other resource for which coroutines might still be waiting at viewer shutdown time. One overload is specifically for when the caller knows the name of the one and only coroutine that will wait on the resource (e.g. because the caller IS that coroutine). That overload honors killreq(). Use getStopListener() to simplify the four existing places where we set up such a listener. Add a fifth: also make WorkQueue listen for viewer shutdown (resolving a TODO comment). Remove LLLUAmanager::terminateScript(), getTerminationList() and the static sTerminationList. In the Lua interrupt callback, instead of checking sTerminationList, call LLCoros::checkStop(). Change LLFloaterLUAScripts terminate-script logic to call LLCoros::killreq() instead of posting on "LLLua" and calling LLLUAmanager::terminateScript(). Drop LLApp::setStatus() posting to "LLLua" LLEventPump: the above makes that moot.
2024-03-15SL-18721 Restore release behaviorAndrey Kleshchev
Closing window correctly caused a significant amount of logout freezes with no known reproes. Temporarily returning to old behavior were thread was killes without closing window and will reenable in later maints to hopefully get a scenario or at least more data of what is causing the freeze.
2024-02-08SL-18721 Shutdown fixes #4Andrey Kleshchev
2024-01-22SL-18721 Shutdown fixesAndrey Kleshchev
1. After window closes viewer still takes some time to shut down, so added splash screen to not confuse users (and to see if something gets stuck) 2. Having two identical mWindowHandle caused confusion for me, so I split them. It looks like there might have been issues with thread being stuck because thread's handle wasn't cleaned up. 3. Made region clean mCacheMap immediately instead of spending time making copies on shutdown
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.
2022-06-09SL-17483: Make it possible to override width of any ThreadPool.Nat Goodspeed
Introduce CommonControl, which in a running viewer (or any program containing an LLViewerControlListener instance) gives access to LLViewerControl functionality, e.g. getting, setting or enumerating control variables -- without introducing a link dependency on newview. Make ThreadPool's constructor consult CommonControl to check for an override for the width of the new ThreadPool in the Global (i.e. gSavedSettings) setting ThreadPoolSizes, and honor that if found. Introduce static ThreadPool methods getConfiguredWidth(), to query for such an override on any particular ThreadPool name; and getWidth(), to ask for the width of an instance if that instance already exists, else the width with which it *would* be instantiated.
2022-06-09SL-17483: Make ThreadPool inherit LLInstanceTrackerCosmic Linden
(cherry picked from commit 41d6a0e222241606c317281e2f0b211e16813dd5)
2021-11-23SL-16400: Add ThreadPool::start() method, and call it.Nat Goodspeed
It's sometimes important to finish other initialization before launching the threads in the ThreadPool, so make that an explicit step. In particular, we were launching the LLImageGL texture thread before initializing the GL context, resulting in all gray textures.
2021-11-05SL-16202: Use WorkQueue::postTo() for texture create/post handshake.Nat Goodspeed
That is, when LLViewerFetchedTexture::scheduleCreateTexture() wants to call createTexture() on the LLImageGLThread, but postCreateTexture() on the main thread, use the "mainloop" WorkQueue to set up the handshake. Give ThreadPool a public virtual run() method so a subclass can override with desired behavior. This necessitates a virtual destructor. Add accessors for embedded WorkQueue (for post calls), ThreadPool name and width (in threads). Allow LLSimpleton::createInstance() to forward arguments to the subject constructor. Make LLImageGLThread an LLSimpleton - that abstraction didn't yet exist at the time LLImageGLThread was coded. Also derive from ThreadPool rather than LLThread. Make it a single-thread "pool" with a very large queue capacity.
2021-11-04SL-16202: Use large WorkQueue size limits for mainloop and General.Nat Goodspeed
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.
2021-10-22SL-16220: Add LL::ThreadPool class and a "General" instance.Nat Goodspeed
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.