Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8] Reporter
	Description • 12 years ago

dcamp said on irc that this might negatively affect tab actors and the `listTabs` method:

> dcamp: some of the weirdness is to account for the listTabs method. A better
> implementation would be welcome, but make sure tab actors don't get disconnected
> just because their lifetime changes (ie they move to a different pool)

I haven't looked in to this yet, but from what I have seen, I assume this problem would arise when `removeActor` is called inside `addActor`. If that is the case, I am thinking of adding a parameter to the `disconnect` method that would signify whether this is a complete disconnect, or a disconnect from the current `ActorPool` that will be follow by a being added to a new `ActorPool`. Something like, `disconnect(isMovingPools)`.

A fix for this bug is needed because actors might be making modifications to their `ActorPool` that they need to clean up on disconnect even if the actor isn't completely shutting down. For example, `ObjectActor`s are added to a pool's `objectActors` weak map. This isn't so much of a problem because weak maps won't hold on to the memory, but for `LongStringActor`s I can't use a weak map because you can't key weak maps with strings and so I use a normal object. This means that if I don't properly remove the `LongStringActor` on every type of disconnect, we will be holding on to references all over the place resulting in the JS equivalent of leaking memory.

	Eddy Bruel [:ejpbruel]
	Comment 1 • 9 years ago

Oops. Looks like I accidentally made bug 1223766 a duplicate of this one. I'm going to close this bug, since I'm actively working on the other one, and already have a patch up for it.