After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 546181 - Async operation cancellation race condition
Async operation cancellation race condition
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Alexander Larsson
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-08-04 07:42 UTC by jessevdk@gmail.com
Modified: 2009-03-03 15:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description jessevdk@gmail.com 2008-08-04 07:42:28 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.
Comment 1 Alexander Larsson 2009-03-03 15:06:30 UTC
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).


Comment 2 jessevdk@gmail.com 2009-03-03 15:20:08 UTC
Cool, from what I understand this solves my problem since I'm cancelling from the main thread.