Bug 52482 - Allow replacing running CMs
Summary: Allow replacing running CMs
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.com/git/user/xc...
Keywords: patch
Depends on:
Reported: 2012-07-25 12:38 UTC by Xavier Claessens
Modified: 2019-12-03 20:40 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

TpConnectionManager: Make possible to replace a running CM (13.60 KB, patch)
2012-07-26 11:11 UTC, Xavier Claessens
Details | Splinter Review

Description Xavier Claessens 2012-07-25 12:38:51 UTC
"telepathy-gabble --replace" should make running gabble close connections and exit, and the new instance takes its place.
Comment 1 Xavier Claessens 2012-07-26 05:42:05 UTC
could do the same for MC
Comment 2 Xavier Claessens 2012-07-26 11:11:39 UTC
Created attachment 64719 [details] [review]
TpConnectionManager: Make possible to replace a running CM

If a CM is started with --replace argument, this cause the running CM
to disconnect all connections and leave.
Comment 3 Simon McVittie 2012-07-26 11:57:45 UTC
(I have not reviewed in detail.)

Doesn't this have a race condition?

old Gabble            new Gabble
has 2 connections
                      takes CM name
loses CM name
closes connections    starts connecting

If the new Gabble starts taking Connection names before the old Gabble has closed and released them, then the new Gabble's RequestConnection() is going to fail.

Perhaps that's OK if MC will try reconnecting or something? But be careful.

Also be very careful with shared resources. If Gabble is writing to a file and assumes it will be the only one doing so because the bus name is a mutex - that assumption isn't true any more.

(In reply to comment #1)
> could do the same for MC

Be very, very careful about this sort of thing in MC. Unlike Gabble, MC does definitely write to several files with non-cache semantics (potential for data loss if something goes wrong). Because delivering and processing a D-Bus message isn't atomic, there may be a window during which the new MC thinks it has the name, but the old MC still thinks it *also* has the name, and is still happy to write to the files.
Comment 4 GitLab Migration User 2019-12-03 20:40:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/99.

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.