Mission Control could improve its tracking of misbehaving CMs
Submitted by Ed Page
Assigned to Telepathy bugs list
Description
Steps to reproduce:
- MC disconnect while the event loop of a CM is blocked (in my case, The One Ring)
- MC create a new connection
Expected Behavior
The Connection cleans up cleanly and a new one is able to be created
Actual Behavior
The connection is leaked. Some CMs don't randomize the Connection name, preventing future connections from being made.
From Mikhail: """ For one thing, I think Mission Control should keep watch on lingering connections even after it has ceased doing anything useful with them, and react to the connection status signals. If the connection comes online after all, it could be treated positively, or it could be immediately told to disconnect just to not muddle the MC state too much. A bug on bugs.freedesktop.org could be filed. """
My own ramblings without knowing the code: If MC waited on recreating a connection until it got Disconnect this would help in the case where Disconnect doesn't block but the event loop is blocked from other processing. The Disconnected signal would fire, causing a RequestConnection. I imagine there is possibility of negative impact with this. I'm also guessing it would be bad to generally monitor for NewConnection and respond to it regardless of an outstanding RequestConnection. This would help in the case of the CM event loop blocking at some point (pre-Disconnect, Disconnect, RequestConnection) and allow cleaning up of that resource.
For more information, see the following thread on Telepathy mailing list http://lists.freedesktop.org/archives/telepathy/2010-March/004343.html
Version: git master