In this case m_agentsInTransit. If this is not shared between scenes then on teleport, I can put a guard against trying
to re-establish an agent in the source region (if, for instance, some script causes an attempt to teleport back very
quickly) before an old agent has been properly cleaned up.
One could simply look for an existing ScenePresence but then you wouldn't be able to tell if that SP was still there due
to some crash or maybe because multiple logins are allowed and the user has some other presence there.
On 23/05/12 01:23, Diva Canto wrote:
Hi Justin,
Usually I write Shared modules if they do generic things that don't depend on
the state of the individual scenes.
Why do you want to make it NonShared? Any state in particular you are looking
at?
Diva / Crista
On 5/21/2012 3:22 PM, Justin Clark-Casey wrote:
Hi Diva (primarily). Is there any strong reason for having EntityTransferModule
as a shared module rather than per
region? I need to keep eliminating possible teleport-related race conditions
and this gets simpler if scenes aren't
sharing the ETM module. Teleports between regions on the same simulator then
better resemble teleports between regions
on different simulators, eliminating the need for special-case logic.
In particular, doing this allows me to extend the in-transit checking to
prevent problems such as teleporting back to
the same region before the old ScenePresence has been properly cleaned up.
There are a couple of shared member variables on ETM (and HGETM) but these are
either unused (m_Scenes) or I don't
think the share has no practical effect (e.g. m_bannedRegions, since this is
only used on region cross). If these
shared structures are important then I could be move them somewhere else.
In my early regression and manual tests there are no obvious issues with making
this change, though I intend to test
more.
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
