Re: GCancellable is not really cancellable?

[Alexander Larsson <alexl redhat com>]

On Mon, 2010-04-26 at 16:04 +0300, Felipe Contreras wrote:
> Hi Alexander,
> 
> On Mon, Apr 26, 2010 at 2:59 PM, Alexander Larsson <alexl redhat com> wrote:
> > On Sun, 2010-04-25 at 22:05 +0300, Felipe Contreras wrote:
> >
> >> So what am I supposed to do? ref() the object each time I do an async
> >> operation, and unref() it each time the operation finishes, while also
> >> keeping an extra field in order to find out if the object has been
> >> disposed?
> >
> > Depends on what you mean by "object". The stream itself is automatically
> > refed when there is an outstanding async operation on it. If you have
> > further data that you need to live until the callback then you have to
> > ref it, or otherwise keep it alive.
> 
> By "object" I mean my custom object that I passed through user_data.
> 
> >> What's the point? Wouldn't it be better to truly cancel the operation?
> >
> > This is how cancellation worked in gnome-vfs, and it has a few problems.
> 
> This how all I/O API's I know work; GIOChannel, libpurple, libevent.
> They have no problems.

GIOChannel have no cancellation api. I don't really know the other apis.

> > First of all, its inherently and unfixably racy in the multi-threaded
> > case. For instance, what if you call cancel() on a thread when the
> > operation just finished and we've called the callback on another cpu.
> > There is no way at this point to stop that emission, and its not
> > reasonably possible to synchronize and have the cancel fail.
> 
> That's what mutexes are for. The cancel() function would wait until
> the emission finishes.

So, you want want the cancellation operation to block the mainloop until
the worker thread has finished cancelling the operation, a potentially
very slow i/o operation? That seems like a very bad idea. It certainly
would make it useless for any gui code.

> > Third, code wise its actually not simpler, because you now get two
> > codepaths that free the data that was allocated for the data (free in
> > callback, or free after cancelling). This leads to convoluted code that
> > is hard to get right. With gio you can *always* assume the callback will
> > be called, and only once, so you can free any data there.
> 
> If you want to free the data in the callback, then don't call
> cancel(). Or make cancel() wait until the callback function has been
> called, and then continue.

Again, sync cancel is not what you want.

> I don't think this scenario, where an object has ownership of a
> GAsyncResult operation and updates itself on the callback, is uncommon
> at all, and the current API is clearly not suited for this. If I want
> to kill the operation, I should be able to, otherwise resources will
> be wasted.

I don't see the problem? Just free the data in the callback, whether
cancelled or not. Any wasting of resources is just until the callback
gets called on the mainloop, which should be more or less instant if
immediate cancallation is possible.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's an underprivileged gay barbarian possessed of the uncanny powers of an 
insect. She's a scantily clad foul-mouthed cab driver descended from a line of 
powerful witches. They fight crime!