On Wed, Mar 10, 2010 at 7:14 AM, <[email protected]> wrote: > To make Mission Control happy, a connection manager should not block its > internal event loop which processes D-Bus method calls, at least at the time > when RequestConnection is called. If the RequestConnection D-Bus call times > out, Mission control will consider the connection failed, and rightly so. > So, if you have any such kind of snags in your protocol stack, you ought to > work around them. Look closely at any blocking calls performed: 1) at connect > time; 2) at connection shutdown so they may leave a connection object > lingering. Consider using asynchronous implementation for such functionality > if available, or put it to a thread.
Originally I had issues with blocking calls in Connection.Connect. Since then I've moved the content of my Connection.Connect call to an idle callback so Connect returns immediately. I've checked RequestConnection, Connect, and Disconnect. I should not be blocking. Looking closer I found a couple more issues in my CM. I'm hoping working around them will reduce the average case for CM response time to RequestConnection/Connect/Disconnect that the user will rare see an issue. Despite my claim that I don't block in Disconnect, somehow my Disconnect took 6 seconds according to one log file. I'm unsure why but this can have a negative impact. My CM shuts down when idle. The countdown starts at the beginning of my Disconnect which if my Disconnect blocks means it will close immediately. That with python's startup time means that if the RequestConnect is what causes DBus to restart my CM then it could have have taken a while. Though if a CM ever blocks the event loop and a Disconnect comes in (or RequestConnect/Connect for another account) then it can't be processed until the blocking call gets back. So we get blocking by side-effect. I can understand the need for the timeout, if something happened to the CM like its hung or crashed then you don't want to wait on it forever. It just seems kind of sad that I have the leisure of running asynchronously and yet I have add an extras layer of asynchronous calls. It also seems worrisome that you give up on a CM without ever notifying it that you gave up. I can understand that in an ideal situation no CM would ever hit this issue but its still good to be defensive, especially when it can impact the user experience (can't reconnect) and battery life (connection got left open with any of its keep-alives firing). Thanks for all the help provided, its been a big benefit to my users Ed Page _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
