Re: GCancellable is not really cancellable?

[Felipe Contreras <felipe contreras gmail com>]

On Mon, Apr 26, 2010 at 4:35 PM, Alexander Larsson <alexl redhat com> wrote:
> On Mon, 2010-04-26 at 16:04 +0300, Felipe Contreras wrote:
>> On Mon, Apr 26, 2010 at 2:59 PM, Alexander Larsson <alexl redhat com> wrote:
>> > 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.

After calling g_io_channel_shutdown() no further callbacks happen.

>> > 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.

So would g_input_stream_read_all(), that's not a reason to remove API
that would be potentially useful for non 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.

Why not? Are you assuming all code is for gui? A separate
cancel_sync(), or discard() would do the trick for non-gui code.

>> 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.

The data is owned by a parent object, which I don't know if it's still
there or not. The big waste of resources is in the extra ref'ing and
unref'ing each time an async operation is issued. This could be solved
if there was a way of detecting when the source object is being
destroyed (after all the async operations have finished).

Cheers.

-- 
Felipe Contreras