Bug 10613 - telepathy-glib: release connections' object paths before their bus names, and do both sooner
Summary: telepathy-glib: release connections' object paths before their bus names, and...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Simon McVittie
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/sm...
Whiteboard: review+
Keywords: patch
Depends on:
Blocks:
 
Reported: 2007-04-11 09:04 UTC by Simon McVittie
Modified: 2010-11-05 04:18 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Simon McVittie 2007-04-11 09:04:21 UTC
16:53 < mikhailz> there should be a way in every binding to unregister the 
                  object path while the object is still around
...
16:54 < mikhailz> smcv: dbus-glib has the same problem, only we can make the 
                  destruction gap almost predictably small
16:54 < smcv> sorry? I don't follow
16:55 < smcv> oh, you're referring to the need to synchronize release of the 
              object path and of the bus name?
16:55 < mikhailz> smcv: there is a short time interval between releasing the 
                  bus name and destroying the object path
16:55 < smcv> I know
16:56 < smcv> ideally the destruction needs to take place in the opposite order
16:56 < smcv> effectively, using the bus name as a mutex
16:56 < smcv> since failing to obtain a bus name fails gracefully, whereas 
              trying to reuse an object path triggers scary warnings and/or 
              assertions
16:56 < smcv> as I said, libdbus hates us
...
16:57 < mikhailz> hm, that gives me an idea for the GLib implementation, 
                  release the bus name in the "afterlife" callback
16:58 < smcv> mikhailz: do you mean finalize as opposed to dispose?
16:59 < smcv> even the approach I use in dbus-python isn't perfect; there's 
              something that can fail (OOM at exactly the wrong moment, I 
              think) that causes me to leak 1 string's worth of memory
16:59 < mikhailz> smcv: no, in the idle callback or something similar
Comment 1 Simon McVittie 2009-04-14 06:37:02 UTC
Reassigning to the mailing list, I'm not going to be doing this any time soon.
Comment 2 Simon McVittie 2010-11-03 11:03:40 UTC
Now that dbus-glib has had 3.5 years of sporadic development and even some new features, we can do this much easier, while simultaneously fixing a bug Vivek reported on IRC in which a lingering connection can cause a new connection attempt to crash.
Comment 3 Simon McVittie 2010-11-03 11:05:18 UTC
Branch:

http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/disappear

However, merging this breaks the Gabble regression tests, because sidecars.py expects a particular error. So, we'll need this, which can be merged at any time:

http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=shortlog;h=refs/heads/test
Comment 4 Simon McVittie 2010-11-03 11:07:39 UTC
(In reply to comment #3)
> However, merging this breaks the Gabble regression tests, because sidecars.py
> expects a particular error. So, we'll need this, which can be merged at any
> time:
> 
> http://git.collabora.co.uk/?p=user/smcv/telepathy-gabble-smcv.git;a=shortlog;h=refs/heads/test

... but imagine it's on the 0.10 branch (I'll cherry-pick).
Comment 5 Simon McVittie 2010-11-03 12:43:17 UTC
(In reply to comment #3)
> However, merging this breaks the Gabble regression tests, because sidecars.py
> expects a particular error.

I fixed that in telepathy-gabble-0.10 and master, for 0.10.5 and 0.11.0 respectively, so no need to review my 'test' branch now.
Comment 6 Vivek Dasmohapatra 2010-11-04 13:09:34 UTC
Reviewd, tested in env where recent bug report arose, looks good
and seems to DTRT.
Comment 7 Simon McVittie 2010-11-05 04:18:22 UTC
Fixed in git for 0.13.5, thanks!

I don't think this should be backported to 0.12, since it's a visible behaviour change to fix a relatively unlikely bug.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.