Re: API update proposal: cancellation notification

[Guillaume Emont <gemont igalia com>]

On 24/01/2011 17:16, Juan A. Suárez Romero wrote:
> On Mon, 2011-01-24 at 16:02 +0000, Iago Toral wrote:
>>  Mmm, good point. That's something I think we should really avoid, 
>>  because if we do that then operations would have 2 finishing points:
>> the 
>>  callback (when they are not cancelled) and the signal (when they
>> are). 
>>  And that's not a good idea IMHO. The whole point of always invoking
>> the 
>>  callback was to ease the operation finalization process after all. I 
>>  guess we could have grilo connect to the signal and invoke the
>> callback 
>>  instead, but sounds kind of tricky and is not what GCancellable
>> users 
>>  would expect...
>>
>
> Note that this is how GIO works. When an operation is cancelled, your
> "callback" is invoked. And there you can check if the operation was
> cancelled or not.
>
> But also provides the signal, which you can connect or not.
Ha, you've been saying in a clearer way what I was writing in another
email at the same time ;)
> Reviewing the API, seems there is a function to set up if cancellation
> is notified to callback through a GError
> (g_cancellable_set_error_if_cancelled()).
>
> In doc, there's an example where this GError notification is disabled
> before connecting to cancelled signal.
g_cancellable_set_error_if_cancelled() doesn't do that. What it does is
allow you to get a GError if the operation has already been cancelled.
The documentation is not obvious on that, but if you have a look at the
implementation, it is.
Also, calling that callback or not is something that seems out of the
scope of GCancellable (it's not up to the GCancellable to decide that).

Guij