Bug 52482

could do the same for MC

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.

(I have not reviewed in detail.)

Doesn't this have a race condition?

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

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.

-- 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.