[Opensim-dev] SceneGraph data access refactoring

[Lake, Dan]

Based on feedback, I am putting in an updated patch this morning on the scene presence access refactoring.

1. Scene.GetScenePresence() will stay with the caveat that the caller must check for null. It's my understanding that this is the pattern preferred by core. There is a variant for UUID, localID and first/last name. 

2. TryGetAvatar() will also remain on SceneManager, SceneBase, Scene and SceneGraph but has been renamed TryGetScenePresence(UUID) since that is what it does and returns a boolean. The same variants exist as for GetScenePresence. (Note: If this is non-prefered then it can be removed unless there is a technical reason that it must stay. The TryGet pattern is used in places for other data such as appearance also.)

3. GetAvatars() and GetScenePresences() have been removed from Scene. To iterate over presences, pass a delegate to Scene.ForEachScenePresence().

Dan lake
Intel Labs
dan.lake at intel.com


From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Lake, Dan
Sent: Thursday, March 18, 2010 4:38 PM
To: opensim-dev at lists.berlios.de
Subject: [Opensim-dev] SceneGraph data access refactoring

I am committing a set of patches this week which make data access and locking of presences within the scene graph more consistent. There are currently many ways to get presence data from the scene graph and/or iterate over it. To name a few, there are GetScenePresence, TryGetAvatar, GetScenePresences and ForEachScenePresence.  Unfortunately, some of these have relied on the callers locking the list or checking for null references which was missing in many places.

The patches move all locking into SceneGraph, eliminate GetScenePresence in favor of TryGetAvatar, and consolidates the two different presence iteration patterns. Instead of calling GetScenePresences() and iterating over the result, modules and other code should call ForEachScenePresence(Action<ScenePresence>) and let SceneGraph do the parallel work. Eventually this will also mean that the list does not need to be copied or locked in order to iterate since it changes infrequently but is iterated my many callers simultaneously.

The goal is to move SceneGraph toward a self-supporting container of entities with properties and a small lightweight interface for adding, removing, and performing actions on the container through the use of properties/components, filters, and delegates. Supporting or allowing a module to grab a reference to the internal array of presences and lock it so that no other thread may add/remove/iterate is seriously limiting scalability and has introduced reliability issues and races between the scene and some modules.

Dan lake
Intel Labs
dan.lake at intel.com