Cancellable#
Superclasses: Object
GCancellable allows operations to be cancelled.
GCancellable is a thread-safe operation cancellation stack used
throughout GIO to allow for cancellation of synchronous and
asynchronous operations.
Constructors#
- class Cancellable
- classmethod new() Cancellable#
Creates a new
Cancellableobject.Applications that want to start one or more operations that should be cancellable should create a
Cancellableand pass it to the operations.One
Cancellablecan be used in multiple consecutive operations or in multiple concurrent operations.
Methods#
- class Cancellable
- cancel() None#
Will set
cancellableto cancelled, and will emit theCancellable::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.If
cancellableisNone, this function returns immediately for convenience.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
AsyncReadyCallbackwill not be invoked until the application returns to the main loop.It is safe (although useless, since it will be a no-op) to call this function from a
cancelledsignal handler.
- connect(callback: Callable[[], None], data: Any = None) int#
Convenience function to connect to the
Cancellable::cancelled signal. Also handles the race condition that may happen if the cancellable is cancelled right before connecting.callbackis called exactly once each timecancellableis cancelled, either directly at the time of the connect ifcancellableis already cancelled, or whencancellableis cancelled in some thread. In case the cancellable is reset viaresetthen the callback can be called again if thecancellableis cancelled and if it had not been previously cancelled at the timeconnectwas called (e.g. if the connection actually took place, returning a non-zero value).data_destroy_funcwill be called when the handler is disconnected, or immediately if the cancellable is already cancelled.See
Cancellable::cancelled for details on how to use this.Since GLib 2.40, the lock protecting
cancellableis not held whencallbackis invoked. This lifts a restriction in place for earlier GLib versions which now makes it easier to write cleanup code that unconditionally invokes e.g.cancel. Note that since 2.82 GLib still holds a lock during the callback but it’s designed in a way that most of theCancellablemethods can be called, includingcancelorunref.There are still some methods that will deadlock (by design) when called from the
cancelledcallbacks:Added in version 2.22.
- Parameters:
callback – The
Callbackto connect.data – Data to pass to
callback.
- disconnect(handler_id: int) None#
Disconnects a handler from a cancellable instance similar to
signal_handler_disconnect(). Additionally, in the event that a signal handler is currently running, this call will block until the handler has finished. Calling this function from aCancellable::cancelled signal handler will therefore result in a deadlock.This avoids a race condition where a thread cancels at the same time as the cancellable operation is finished and the signal handler is removed. See
Cancellable::cancelled for details on how to use this.If
cancellableisNoneorhandler_idis0this function does nothing.Added in version 2.22.
- Parameters:
handler_id – Handler id of the handler to be disconnected, or
0.
- classmethod get_current() Cancellable | None#
Gets the top cancellable from the stack.
- get_fd() int#
Gets the file descriptor for a cancellable job. This can be used to implement cancellable operations on Unix systems. The returned fd will turn readable when
cancellableis cancelled.You are not supposed to read from the fd yourself, just check for readable status. Reading to unset the readable status is done with
reset().After a successful return from this function, you should use
release_fd()to free up resources allocated for the returned file descriptor.See also
make_pollfd().
- make_pollfd(pollfd: PollFD) bool#
Creates a
PollFDcorresponding tocancellable; this can be passed topoll()and used to poll for cancellation. This is useful both for unix systems without a native poll and for portability to windows.When this function returns
True, you should userelease_fd()to free up resources allocated for thepollfd. After aFalsereturn, do not callrelease_fd().If this function returns
False, either nocancellablewas given or resource limits prevent this function from allocating the necessary structures for polling. (On Linux, you will likely have reached the maximum number of file descriptors.) The suggested way to handle these cases is to ignore thecancellable.You are not supposed to read from the fd yourself, just check for readable status. Reading to unset the readable status is done with
reset().Note that in the event that a
cancelledsignal handler is currently running, this call will block until the handler has finished. Calling this function from a signal handler will therefore result in a deadlock.Added in version 2.22.
- Parameters:
pollfd – a pointer to a
PollFD
- pop_current() None#
Pops
cancellableoff the cancellable stack (verifying thatcancellableis on the top of the stack).
- push_current() None#
Pushes
cancellableonto the cancellable stack. The current cancellable can then be received usingget_current().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.
Fileoperations, so you rarely have to call this yourself.
- release_fd() None#
Releases a resources previously allocated by
get_fd()ormake_pollfd().For compatibility reasons with older releases, calling this function is not strictly required, the resources will be automatically freed when the
cancellableis finalized. However, thecancellablewill block scarce file descriptors until it is finalized if this function is not called. This can cause the application to run out of file descriptors when manyCancellableare used at the same time.Note that in the event that a
cancelledsignal handler is currently running, this call will block until the handler has finished. Calling this function from a signal handler will therefore result in a deadlock.Added in version 2.22.
- reset() None#
Resets
cancellableto its uncancelled state.If cancellable is currently in use by any cancellable operation then the behavior of this function is undefined.
Note that it is generally not a good idea to reuse an existing cancellable for more operations after it has been cancelled once, as this function might tempt you to do. The recommended practice is to drop the reference to a cancellable after cancelling it, and let it die with the outstanding async operations. You should create a fresh cancellable for further async operations.
In the event that a
cancelledsignal handler is currently running, this call will block until the handler has finished. Calling this function from a signal handler will therefore result in a deadlock.
- set_error_if_cancelled() bool#
If the
cancellableis cancelled, sets the error to notify that the operation was cancelled.
- source_new() Source#
Creates a source that triggers if
cancellableis cancelled and calls its callback of typeGCancellableSourceFunc. This is primarily useful for attaching to another (non-cancellable) source withadd_child_source()to add cancellability to it.For convenience, you can call this with a
NoneCancellable, in which case the source will never trigger.The new
Sourcewill hold a reference to theCancellable.Added in version 2.28.
Signals#
- class Cancellable.signals
- cancelled() None#
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
signal_handler_disconnect()for that handler has already returned.There is also a problem when cancellation happens 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.
In order to make it safe and easy to connect handlers there are two helper functions:
connect()anddisconnect()which protect against problems like this.An example of how to us this:
// Make sure we don't do unnecessary work if already cancelled if (g_cancellable_set_error_if_cancelled (cancellable, error)) return; // Set up all the data needed to be able to handle cancellation // of the operation my_data = my_data_new (...); id = 0; if (cancellable) id = g_cancellable_connect (cancellable, G_CALLBACK (cancelled_handler) data, NULL); // cancellable operation here... g_cancellable_disconnect (cancellable, id); // cancelled_handler is never called after this, it is now safe // to free the data my_data_free (my_data);
Note that the cancelled signal is emitted in the thread that the user cancelled from, which may be the main thread. So, the cancellable signal should not do something that can block.