On Mon, Mar 15, 2010 at 9:07 AM, <[email protected]> wrote: > Yes, it was a problem with our implementation: blocking on disconnection > meant that a RequestConnection call to reestablish the connection timed out. > Even if blocking is resolved, making an object linger in disconnecting state > will keep the DBus object path occupied, so if the connection object paths > are not randomized, this will result in a conflict if the connection is > restarted.
Is it a best practice to randomize the paths? Telepathy-python provides a default implementation for building the path and doesn't randomize it. If it is a best practice then I'll send a bug over their way. > Well, as a general rule, a D-Bus service should not block for potentially > long periods of time while handling method calls. By extension, it means that > the service's event loop processing DBus messages should not have such > blockers at all. There is no good alternative to being async. > 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. > But the case of a RequestConnection timeout is worse: you don't get a > connection object to watch, and DBus will not route your call result back > even if the CM ultimately responds. Life is tough for misbehaving services. Now filed https://bugs.freedesktop.org/show_bug.cgi?id=27101 I saw a comment somewhere about not blocking and was hoping it wouldn't be an issue but I can see why it is. I guess I'll go clean it up. Thanks for the pointers though in helping identify why it was misbehaving. Ed Page _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
