aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/ThirdParty/SmartThreadPool/PriorityQueue.cs
diff options
context:
space:
mode:
authorJustin Clark-Casey (justincc)2013-08-01 18:12:28 +0100
committerJustin Clark-Casey (justincc)2013-08-01 18:12:28 +0100
commit0c4c084bed5175d8a5b25b8f915363f3b15b6e3a (patch)
tree715fa74d0ce34d4066e751e590369aec548a179d /ThirdParty/SmartThreadPool/PriorityQueue.cs
parentRevert "Issue: painfully slow terrain loading. The cause is commit d9d995914c... (diff)
downloadopensim-SC_OLD-0c4c084bed5175d8a5b25b8f915363f3b15b6e3a.zip
opensim-SC_OLD-0c4c084bed5175d8a5b25b8f915363f3b15b6e3a.tar.gz
opensim-SC_OLD-0c4c084bed5175d8a5b25b8f915363f3b15b6e3a.tar.bz2
opensim-SC_OLD-0c4c084bed5175d8a5b25b8f915363f3b15b6e3a.tar.xz
Try a different approach to slow terrain update by always cycling the loop immediately if any data was sent, rather than waiting.
What I believe is happening is that on initial terrain send, this is done one packet at a time. With WaitOne, the outbound loop has enough time to loop and wait again after the first packet before the second, leading to a slower send. This approach instead does not wait if a packet was just sent but instead loops again, which appears to lead to a quicker send without losing the cpu benefit of not continually looping when there is no outbound data.
Diffstat (limited to 'ThirdParty/SmartThreadPool/PriorityQueue.cs')
0 files changed, 0 insertions, 0 deletions