Remove all references to LLQueuedThread (but emulate a couple bits of its API
such as handle_t and getPending()).
Migrate ImageRequest into llimageworker.cpp. It has never been part of
LLImageDecodeThread's public API. Remove ImageRequest tests.
Remove all references to LLImageDecodeThread::pause(). The idea of pausing
another thread is bizarre to me, and LLThreadPool has no such operation. Nor
does it have an abortRequest().
This picks up ThreadPoolSizes override logic embedded in ThreadPool's
constructor, plus the new static ThreadPool::getConfiguredWidth() and
getWidth() methods.
Now that LL::ThreadPool's constructor has subsumed the work of discovering a
runtime override width, LLAppViewer::initGeneralThread() can simply pass the
compile-time default width instead of redundantly checking ThreadPoolSizes.
Also the default ThreadPool capacity has been bumped up to what "General" and
"LLImageGL" were requesting, so they need not pass that explicitly or explain
in comments why they're doing it.
But until we start throwing work at the "General" ThreadPool, configure it
down to 1 thread in settings.xml.
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.
This was affecting map tiles that the agent is not allowed to see (HTTP error: 403 forbidden). The URLs of these map tile requests were then getting cleared, so when these map tiles were re-requested (up to 10 times per second, from LLViewerFetchedTexture::updateFetch), the request would use the wrong URL and get a 404.
Stay in DONE state if there is no new work to do, reducing unneeded requests for textures while leaving open the possibility to re-request a texture at different resolution. Alternatively, we could introduce a new FAILED state here. The current DONE state has nuance, and can either mean "texture loading failed" or "texture successfully loaded at a certain LOD." And a 4xx error is generally irrecoverable. Will strongly consider a FAILED state.
Also, don't clear the map URL, so that any future network requests for the map textures request the correct resource.
Sabrina Shanman