* Entities should now in theory be lock-free externally.
* Other properties may cause blocking however[?].
* ScenePresence maintains separate locks so isn't fixed by this commit.
* Important Changes: Scene.Entities is now IEnumerable directly. You do not need to use Entities.Values, you can Enumerate on .Entities directly. (So 'foreach Scene.Entities' vs 'foreach Scene.Entities.Values').
* Locks: Entities maintains it's own internal locking states. This means you do not need to lock entities anymore. I'll be going through and removing locks on it systematically.
* Not referenced anywhere yet.
* Designed to replace Dictionary<UUID,EntityBase> within SceneGraph.Entities
* Allows indexed access and better handling of locks.
* Someone needs to implement IEnumerable on this before we can switch it over.
from the presence module to the message server, through the user server
and on into the database. This should fix the "Already logged in" issue
that grids see after a sim crashes, or a user crashes out of a sim.
Not yet a 100% solution for friends, but getting there.
This patch adds the option of adding the email when you create
a new user. This works in Gridmode as none Gridmode. This
option is also added to RemoteAdminPlugin. With a new handler
you can create a user with a email.
- I first did lock on m_scenes for that access, but as m_scenes (currently) is
only changed in Initialise (and locked there), and PostInitialise is called
after the calls to Initialise, there shouldn't be a need to lock here.
- Trying out git-svn dcommit. Hope this works.
* SceneObjectPartInventory.cs isn't a particularly good name but it's probably not got a long life
* A proper inventory interface to follow
* Parallel changes for other inventory partial classes to follow at a later date
* Deleting the object before the async to inventory is bad since if OpenSim crashes (or is shutdown!) in the time inbetween, then the object is lost
* Also now delete the object from the scene only after it has gone to inventory - in the old way there was still a race condition
* This is still not ideal since the 'deleted' object remains in the scene and probably could be manipulated. But this is better than the alternative
* Last time I accidentally left the existing code in place that merely wiped the group from the client (but not the scene)
* Put in an incomplete 'delete object o inventory' test to assert that this happens
lbsa71