Mike Thomas 5b6c9a71e5 Fix a bit of a memory leak wherein if a DObject happened to be destroyed prior to its clients unsubscribing, that DObject would be kept until the sessions still subscribed to that object logged off. Due to various client-side timing bits this could happen even if the server sends a message to clients that causes them to unsubscribe prior to calling destroyObject. ...

A concrete example of this is on PlaceObjects - If the server tells users to leave a place and then calls shutdown on the PlaceManager, thus destroying the object, the client will receive the leave-place message, queue up an unsubscribe, receive the destroy message, remove the object from their object cache, and then be unable to unsubscribe back to the server due to no longer having the DObject in question.

Now, if a PresentsSession received a destroy event for an object its client is subscribed to, it will delete the subscription, and instead note the oid as a destroyed subscription for use in validation if lingering unsubscribe requests are pending (they can frequently be).  This still potentially leaks the oid int until the session is ended, but the DObject can be collected.



git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6475 542714f4-19e9-0310-aa3c-eee0fc999fb1

2011-02-03 19:28:34 +00:00

..

com/threerings

Fix a bit of a memory leak wherein if a DObject happened to be destroyed prior to its clients unsubscribing, that DObject would be kept until the sessions still subscribed to that object logged off. Due to various client-side timing bits this could happen even if the server sends a message to clients that causes them to unsubscribe prior to calling destroyObject.

2011-02-03 19:28:34 +00:00