Skip to content

[gnome-3-30] online-accounts: Track the lifecycle of CcGoaPanel across async calls

Debarshi Ray requested to merge wip/rishi/issue-208-gnome-3-30 into gnome-3-30

online-accounts: Track the lifecycle of CcGoaPanel across async calls

Due to an API bug in GNOME Online Accounts, the asynchronous goa_provider_get_all method doesn't accept a GCancellable argument. This makes it difficult to cancel an ongoing call when the CcGoaPanel gets destroyed.

Prior to commit c26f8ae0, this was hacked around by taking a reference on the panel for the duration of the call. Instead of cancelling a pending call on destruction, it would keep the panel alive until the call was over. However, that was lost during commit c26f8ae0.

One thing to bear in mind is that GtkWidgets, CcGoaPanel is one, can be destroyed by a gtk_widget_destroy call, which is subtly different than a simple sequence of g_object_unref calls. When gtk_widget_destroy is used, it invokes the GObject::dispose virtual method of the widget. It is expected this will cause anything holding a reference to this widget to drop their references, leading to GObject::finalize being called. However, there is no guarantee that this will happen in the same iteration of GMainLoop. Therefore, it is possible that when the goa_provider_get_all call finishes, CcGoaPanel might be in a disposed, but not yet finalized state.

When a GObject is in a disposed-but-not-finalized state, only a very limited number of operations can be performed on it. Its reference count can be altered, the memory used by the instance struct can be accessed, but none of the member GObjects can be assumed to be valid. eg., it's definitely illegal to add new rows to the member GtkListBox. Hence a boolean flag is used to mark the destroyed state of the panel.

This second part is a small improvement over the earlier hack.

#208 (closed)

Edited by Debarshi Ray

Merge request reports