Rationale: LL is doing all throttling per service (host:port), not per
service hostname. Also, textures and capabilities use the same host: the
sim you are connected to. Splitting the queues up on a per-service basis
will stop the textures from blocking a capability request.
After commit things compile again :).
The HTTP bandwidth throttling is not yet implemented. I'll put a
temporary fix back the next commit that just does it the "old way"...
Points to the AIPerHostRequestQueue instance corresponding to the
hostname in LLTextureFetchWorker::mUrl. This is basically a cache as we
could of course just retrieve that instance from mUrl at any time,
everytime. Needed in a future commit.
This includes also non-texture requests (not sure if it's worth it to
explicitely separate this data for just textures).
The texture console now prints: HTTP:c/q/a/r
Where, c = number of 'add' request commands in the command queue
(minus the number of 'remove' request in the command queue and not
taking into account the command_being_processed, nor entirely being
thread-safe with regard to adding requests to 'q' or 'a' next: it is
possible that a request is no longer counted in 'c' but not yet is added
to 'q' or 'a'.
q = number of queued (throttled) requests (by the curl thread).
a = number of actually added requests (to the multi handle).
r = last returned value of 'running handles' by libcurl.
Obviously, c and q should be small (0 or 1) most of the time and a and r
should be equal and maxed out. This turns out to be the case.
Renamed PerHostRequestQueue and PerHostRequestQueuePtr to
AIPerHostRequestQueue and AIPerHostRequestQueuePtr respectively and
moved them to global namespace. This in preparation for using them in
the texture fetcher (as function of the hostname of the url that is
contructed there).
This new variable is updated to contain the total number of requests in
MultiHandle::mAddedEasyRequests. It can be a static because MultiHandle
is a singleton (there is only one curl thread) and it has to be an
(atomic) static because we don't want to need to take the lock on
MultiHandle for accessing this variable.
The new variable is updated to contain the sum of the size of
PerHostRequestQueue::mQueuedRequests of every PerHostRequestQueue
object, and thus the total number of queued requests for all hosts
together.
Also added PerHostRequestQueue::host_queued_plus_added_size() which
returns the the sum of queued requests plus the requests already added
to the multi handle for this particular hostname.
This adds a size (command_queue_st::size) to the ThreadSafe deque<Command> that was
AICurlPrivate::command_queue that is kept equal to the number of 'add'
commands in the deque minus the number of 'remove' commands in the
deque. The deque itself is now command_queue_st::commands.
Replaces LLTextureFetch::getNumHTTPRequests.
Returns AICurlInterface::Stats::running_handles.
This is work in progress that temporarily doesn't compile because
LLTextureFetch::getNumHTTPRequests is still being used somewhere.
Added a constraint to ensure that the avatar's height (with offset)
does not go below 0.1 meters. Camera was getting confused since the avatar's
effective height was negative.
Note the avatar is mostly underground/contorted even at 0.1 meters, but
most users setting values this low will be making ultra-tinies and would
be hiding the avatar mesh. Camera stays above ground when height is at 0.1.
Conflicts:
indra/llappearance/llavatarappearance.cpp
Instead of focusing the chat bar when the chat history floater is visible, focus it onFocusReceived
This avoids the floater grabbing focus when returning from mouselook.
We were getting the texture ID from the type,index couple, but were not
passing in index, which defaulted to 0. texture ID is available from the
texture object itself, so using that and removing the index parameter
to prevent future confusion.
Conflicts:
indra/newview/llvoavatarself.cpp
If log_path is empty, we shouldn't setChatLogsDir to it.
In fact, this may have been the cause of something Nomade Zhao brought up.
Also, InstantMessageLogPathAnyAccount was accidentally being set as a PerAccount
All HTTP timing is done by AIHTTPTimeoutPolicy.
Inside LLTextureFetchWorker::doWork when mState == SEND_HTTP_REQ,
mCanUseHTTP is true, throttling is not in effect and mURL is not empty,
mLoaded is set to FALSE, mState is set to WAIT_HTTP_REQ and
LLHTTPClient::request is called that starts the download by curl.
A call back to LLTextureFetchWorker::callbackHttpGet is guaranteed,
which causes mLoaded to be set to TRUE (HTTPGetResponder::completedRaw
calls LLTextureFetchWorker::callbackHttpGet which sets mRequestedSize to -1
(if there was an error) and mLoaded to TRUE).
Being in state WAIT_HTTP_REQ, once mLoaded == TRUE (and mRequestedSize
is -1), the different timeout errors are handled.
This reverts commit 63dcd7ba32.
That commit is nonsense and only shows that Liru has no clue what he is
doing when it comes to the snapshot stuff :/.
And no, I wasn't even AWARE he made this commit, I was just happily
exploring and wanted to make a few snapshots when I suddenly noticed
that several things were BROKEN: the aspect that the fullscreen preview
was shown with was wrong, and when I wanted to limit the aspect of my
feed upload that wasn't possible anymore ?!?!?? WTF
Please don't screw up the hard work of others without at LEAST first
consulting them.
This fixes
https://code.google.com/p/singularity-viewer/issues/detail?id=714
The problem was a typo in AIStateMachine::sleep, >= should have been <=
which caused a state machine that uses yield_ms() to never run anymore
when next run it already should have run again. AIFilePicker is the only
state machine that currently uses yield_ms and I hadn't spotted this
because I don't have plugin messages on by default which made my viewer
just that much faster that it the yield never expired the first run
already (causing it to expire immediately).
The rest of the changes in this commit are just minor improvements /
conformation to the EXAMPLE_CODE in aistatemachine.cpp.
This fixes https://code.google.com/p/singularity-viewer/issues/detail?id=705
Adds 'bool redirect_status_ok(void) const { return true; }' to LLIamHere,
because it's ok to receive a 302 status there. Likewise added to LLIamHereVoice,
because that has the same comment in its error() method.
Also fixes the problem that if two redirects occur on a row, then the
upload_finished detection asserted because it would detect the third
time that libcurl turned off writing to the socket as a failure (the
second time wasn't a problem because mUploadFinished was reset upon
receiving the first 302 header, but not upon receiving the second
header).
