GNOME Bugzilla – Bug 546181
Async operation cancellation race condition
Last modified: 2009-03-03 15:20:08 UTC
While working on porting some gnome-vfs code to gio, I noticed a condition in the async/cancellation process where a cancellation didn't get passed to the async callback function. The situation is as follows: 1. Start async operation 2. Async operation finishes, adds idle func to run callback in main loop 3. Cancelled state of the GCancellable object is set, but async operation is already finished 4. Idle callback is called, but _finish function doesn't detect the cancelled state In my opinion, the _finish function should result in G_IO_ERROR_CANCELLED because although the operation itself finished, the callback from a user point of view is also part of the operation. For instance, when an object is destroyed, I cancel a GCancellable associated with an async function related to the object. When there is a case such as the above one, the callback doesn't notice the cancellation, but the object on which I operate is actually gone. This forces me at the moment to construct a separate struct containing the object and the cancellable and pass that to the async function, then check in the callback manually if the cancellable is in the cancelled state.
In the general case you can't rely on calling cancel to trigger a G_IO_ERROR_CANCELLED. There are unfixable races in this. However, as per bug 562452 we now do a lot better in the case where this can be guaranteed (canceling an async operation from the main thread).
Cool, from what I understand this solves my problem since I'm cancelling from the main thread.