summaryrefslogtreecommitdiff
path: root/src/libostree/ostree-async-progress.c
Commit message (Collapse)AuthorAgeFilesLines
* Update FSF license notices to use URL instead of addressJoseph Marrero2021-12-071-3/+1
|
* libostree: Add ostree_async_progress_copy_state()Philip Chimento2019-11-201-0/+34
| | | | | | | | | | | | This allows copying the state from one OstreeAsyncProgress object to another, atomically, without invoking the callback. This is needed in libflatpak, in order to chain OstreeAsyncProgress objects so that you can still receive progress updates when iterating a different GMainContext than the one that the OstreeAsyncProgress object was created under. See https://github.com/flatpak/flatpak/pull/3211 for the application of this API.
* async-progress: Plug memory leak while destroying GSourceUmang Jain2019-10-251-1/+1
| | | | See https://gitlab.gnome.org/GNOME/glib/commit/71973c722
* lib/progress: Fix leak of GSourceColin Walters2018-09-281-1/+1
| | | | | | | Closes: https://github.com/ostreedev/ostree/issues/1738 Closes: #1741 Approved by: jlebon
* Add SPDX-License-Identifier to source filesMarcus Folkesson2018-01-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | SPDX License List is a list of (common) open source licenses that can be referred to by a “short identifier”. It has several advantages compared to the common "license header texts" usually found in source files. Some of the advantages: * It is precise; there is no ambiguity due to variations in license header text * It is language neutral * It is easy to machine process * It is concise * It is simple and can be used without much cost in interpreted environments like java Script, etc. * An SPDX license identifier is immutable. * It provides simple guidance for developers who want to make sure the license for their code is respected See http://spdx.org for further reading. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Closes: #1439 Approved by: cgwalters
* tree-wide: Remove Emacs modelinesColin Walters2017-09-211-2/+1
| | | | | | | | | We added a `.dir-locals.el` in commit: 9a77017d87b74c5e2895cdd64ad098018929403f There's no need to have it per-file, with that people might think to add other editors, which is the wrong direction. Closes: #1206 Approved by: jlebon
* libostree: Fix potential use of uninitialised memory in progress APIPhilip Withnall2017-05-051-0/+2
| | | | | | | Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #835 Approved by: cgwalters
* libostree: Allow OstreeAsyncProgress:status to be set atomicallyPhilip Withnall2017-04-291-16/+37
| | | | | | | | | | | | | | | | | | | | | | Rework how the status is handled in OstreeAsyncProgress so that it’s now a well-known key in the hash table. This means that it can be retrieved and set atomically with other keys using ostree_async_progress_[get|set](). The behaviour of ostree_async_progress_[get|set]_status() is preserved, with the caveat that `status` can now also be accessed using the other API on OstreeAsyncProgress, and has to be accessed with the right GVariant type. Internally, a NULL status is represented by an empty status string (since ostree_async_progress_[get|set]_variant() deliberately don’t allow NULL variants to be set against keys, since that would break the ostree_async_progress_get() API). Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #819 Approved by: cgwalters
* libostree: Add multiple getter/setter support to OstreeAsyncProgressPhilip Withnall2017-04-291-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OstreeAsyncProgress is thread-safe: it can have keys changed by one thread while another is getting the same keys (modulo some locking contention). However, the thread safety is done at the function call level: if some code calls an OstreeAsyncProgress getter several times, the key fetches are not atomic with respect to each other. In the case of contention on the lock, this can result in consumers of OstreeAsyncProgress data seeing an inconsistent state between the properties they query, which could result in progress reporting inaccuracies. In the uncontested case, this results in the OstreeAsyncProgress lock being locked and unlocked many times more than necessary. Try to improve this by adding new API, which supports getting and setting multiple keys atomically: • ostree_async_progress_get() • ostree_async_progress_set() The new API uses GVariants and varargs: keys are passed as a GVariantType string followed by arguments as for g_variant_new() or g_variant_get(), followed by the next key, etc. Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #819 Approved by: cgwalters
* libostree: Rework OstreeAsyncProgress to use GVariants internallyPhilip Withnall2017-04-291-60/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OstreeAsyncProgress currently does some contortions to try and avoid allocating space for guints and guint64s (on 64-bit platforms), but this means it uses two GHashTables. A GHashTable allocates 8 buckets even when empty. Given that the largest usage of OstreeAsyncProgress in libostree puts 13 uints and 5 uint64s in it, this optimisation does not save significant (if any) memory. Instead, change OstreeAsyncProgress to store values internally as GVariants, and expose this with some new API: • ostree_async_progress_get_variant() • ostree_async_progress_set_variant() Each GVariant is allocated on the heap. As they are immutable, they are thread-safe once returned by a getter. The existing API continues to work as before, except in the case where a key is set/got as both a uint and a uint64 — there will now be a collision (and a GVariant type checking failure) whereas previously there was no collision. Nothing in OSTree uses OstreeAsyncProgress this way though. The new API can be used to share more complex data via the progress API. Signed-off-by: Philip Withnall <withnall@endlessm.com> Closes: #819 Approved by: cgwalters
* docs: Get API docs working againMathnerd3142016-06-091-1/+1
| | | | | | | | | | | | | | This changes around a few things that didn't work for me: * Section names seem to be ostree-* instead of libostree-* * Also XML files are ostree-* (they didn't show up at all) - gtk-doc doesn't seem to parse const _OSTREE_PUBLIC correctly * pull documentation is now on the actual functions rather than stubs * Update gitignore with some more files And there some changes to make gtk-doc give fewer warnings (not finished) Closes: #327 Approved by: cgwalters
* Remove unnecessary #include "libgsystem.h"Matthew Barnes2015-05-061-1/+0
|
* libostree: Add _finish() API to async progressColin Walters2014-04-291-3/+41
| | | | | Since OstreeAsyncProgress queues to the mainloop, we might "lose" the last message. Give callers a way to force a flush.
* Add OstreeAsyncProgress, use it for ostree_repo_pullColin Walters2013-10-241-0/+272
Several APIs in libostree were moved there from the commandline code, and have hardcoded g_print() for progress and notifications. This isn't useful for people who want to write PackageKit backends, custom GUIs and the like. From what I can tell, there isn't really a winning precedent in GLib for progress notifications. PackageKit has the model where the source has GObject properties that change as async ops execute, which isn't bad...but I'd like something a bit more general where say you can have multiple outstanding async ops and sensibly track their state. So, OstreeAsyncProgress is basically a threadsafe property bag with a change notification signal. Use this new API to move the GSConsole usage (i.e. g_print()) out from libostree/ and into ostree/.
View Lorry Controller Status