Re: GCancellable hints

[Alexander Larsson <alexl redhat com>]

On Mon, 2009-08-24 at 17:03 +0100, Richard Hughes wrote:
> In the last few weeks I subclassed GCancellable into a ZifCancellable
> object, which allowed me to complete a personal project. I now want to
> do the same for PackageKit, and think perhaps the functionality should
> be abstracted and pushed upstream into Glib as it's the second time
> I'm doing this. I'm asking for your opinions to see if it's the sort
> of thing you want in Glib.
> 
> For me, a "task" can often do actions that cannot be cancelled for
> some time (when dealing with hardware and calling out to other
> programs), so for PackageKit, the install method:
> 
> * depsolves (user can cancel)
> * downloads a package (user can cancel)
> * installs the package using rpm/apt/etc (user CANNOT cancel)
> * updates databases (user can cancel)

As benjamin said, this complex interaction is not really what a
cancellable is. A cancellabe is just a way to cancel a blocking
operation, and has a much "looser" connection to the cancelled code than
this.

> And in the UI, we want to make the [Cancel] button insensitive for
> some of the actions rather that letting the user click it and wait for
> ages with no feedback.
> 
> The only functionality that ZifCancellable adds is two methods:
> 
> void zif_cancellable_set_hint (GCancellable *cancellable, gboolean can_cancel);
> gboolean zif_cancellable_get_hint (GCancellable *cancellable);
> 
> And added the "hint-changed" signal
> 
> void hint_changed_cb (GCancellable *cancellable, gboolean can_cancel,
> gpointer user_data)

This sounds problematic wrt threads and reentrancy. For example, if you
use an async operation implemented using a second thread then set_hint()
will be called in the i/o thread, and the hint-changed signal will be
emitted there. This means you have to be very careful in the
hint-changed signal handler, locking things, etc. 

For sync calls or true async implementations reentrancy is the problem.
You'd call some complex chain of sync operations, and somewhere deep
inside some i/o operation we emit the hint-changes signal, which sorta
reenters your code. For instance if you then grab a lock in the
hint-changed signal handler that would deadlock if the code around it
had that lock. This is of course means that the locking that was
necessary in the above case now is forbidden, as it may deadlock.

Callbacks like this in general code is just not a good idea, it leads to
all the problems we had with the auth callbacks in gnome-vfs. Which is
why I designed gvfs such that it didn't have these issues.