Prevents stealing IDs of animations, sounds and textures from prim
inventories. Prevents copybot from gathering the wearable UUIDs needed for
pirating things from vendors.
allowing the decoded sculpt map cache path to be defined in
the configuration files.
Use DecodedSculpMapPath in the [Startup] section to set
the path. The default is still ./bin/j2kDecodeCache
Signed-off-by: Melanie <melanie@t-data.com>
This patch also fixes a large amount of trailing whitespace. While this is
beneficial, it should really be in a separate patch that fixes whitespace only.
Just good practice.
The separate remove and set operations is SOG.set_UUID() are both locked under m_parts.SyncRoot since they are logically atomic (though this isn't such an issue if the SOG isn't part of a scene)
Added unit test for this behaviour.
Also changed the second m_parts.AddOrReplace() to m_parts.Add(). As the old reference is now removed we never end up replacing an identical uuid. And if we replace a uuid that's already there (from a child part) then this is an error.
Object updates are sent on the task queue. It's possible for an object update to be placed on the client queue before a kill packet comes along.
The kill packet would then be placed on the state queue and possibly get sent before the update
If the update gets sent afterwards then client get undeletable no owner objects until relog
Placing the kills in the task queue should mean that they are received after updates. The kill record prevents subsequent updates getting on the queue
Comments state that updates are sent via the state queue but this isn't true. If this was the case this problem might not exist.
This is necessary because it was still possible for an entity update packet to be constructed, the thread to pause, a kill to be sent on another thread, and then the original thread to resume and send the update
This would result in an update being received after a kill, which results in undeletable ghost objects until the viewer is relogged
Extending the lock looks okay since its only taken by kill, update and reprioritize, and both kill and update do not take further locks
However, evidence suggests that there is still a kill/update race somewhere
Previously, deadlock was possible because deleting a group took a SOG.Children lock then an m_entityUpdates.SyncRoot lock in LLClientView
At the same time, a thread starting from LLClientView.ProcessEntityUpdates() could take an m_entityUpdates.SyncRoot lock then later attempt to take a SOG.Children lock in PermissionsModule.GenerateClientFlags() and later on
Taking a children list in SOG appears to be a better solution than changing PermissionsModule to not relook up the prim. Going the permission modules root would require that all downstream modules not take a SOG.Children lock either
Melanie