Creates a new Cancellable object.

Applications that want to start one or more operations that should be cancellable should create a Cancellable and pass it to the operations.

One Cancellable can be used in multiple consecutive operations, but not in multiple concurrent operations.

Checks if a cancellable job has been cancelled.

If the cancellable is cancelled, throws a GError to notify that the operation was cancelled.

Gets the top cancellable from the stack.

Pops cancellable off the cancellable stack (verifying that cancellable is on the top of the stack).

Pushes cancellable onto the cancellable stack. The current cancllable can then be recieved using cancellableGetCurrent .

This is useful when implementing cancellable operations in code that does not allow you to pass down the cancellable object.

This is typically called automatically by e.g. File operations, so you rarely have to call this yourself.

Resets cancellable to its uncancelled state.

Will set cancellable to cancelled, and will emit the "cancelled" signal. (However, see the warning about race conditions in the documentation for that signal if you are planning to connect to it.)

This function is thread-safe. In other words, you can safely call it from a thread other than the one running the operation that was passed the cancellable.

The convention within gio is that cancelling an asynchronous operation causes it to complete asynchronously. That is, if you cancel the operation from the same thread in which it is running, then the operation's AsyncReadyCallback will not be invoked until the application returns to the main loop.

Emitted when the operation has been cancelled.

Can be used by implementations of cancellable operations. If the operation is cancelled from another thread, the signal will be emitted in the thread that cancelled the operation, not the thread that is running the operation.

Note that disconnecting from this signal (or any signal) in a multi-threaded program is prone to race conditions. For instance it is possible that a signal handler may be invoked even after a call to signalHandlerDisconnect for that handler has already returned.

There is also a problem when cancellation happen right before connecting to the signal. If this happens the signal will unexpectedly not be emitted, and checking before connecting to the signal leaves a race condition where this is still happening.