Re: API update proposal: cancellation notification

[Lionel Landwerlin <lionel g landwerlin linux intel com>]

On Mon, 2011-01-24 at 17:16 +0100, 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.
> 
> 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.
> 
> 	J.A.

Also an interesting point of using GIO is that it becomes easier to use
a thread for plugins or even a thread per plugin. The last case could
provide the ability to write  synchronous code in plugins and thus
simplify the implementation (which is, for Tracker for example, quite
painful).

Regards,

--
Lionel Landwerlin