TpIfaceChannelFactory has a close_all() method, which is called by TpBaseConnection before the connection moves to state Disconnected. Currently, TpChannelManager does not have a corresponding method; instances are expected to listen for the TpSvcConnection::status-changed signal and close their channels when the connection moves to Disconnected. But this reverses the "Channels all close; Connection goes to Disconnected" ordering. If this matters, we could either create tp_channel_manager_close_all(), or add a TpBaseConnection::disconnect-imminent(guint reason) signal, both of which would allow channels to be closed (or possibly change Group membership, as appropriate) before StatusChanged appears on the bus. Simon says: > TpChannel will do the > right thing even if the Channel Closed signal never comes (it'll become > invalidated with an error in domain TP_ERRORS_DISCONNECTED whose code is > a TpConnectionStatusChangedReason, I believe - and that's at least as > informative as anything the Channel could come up with on its own!) so > perhaps we don't need that.
This reversal of order, and the consequent invalidation Simon describes, prevents us emitting delivery reports on channels to say “hey the connection's going away these messages which weren't yet written to the socket aren't going to be sent”; or rather, we can emit them just fine, but no UI will care because their proxy was already invalidated.
-- 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/4.
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.