summaryrefslogtreecommitdiff
path: root/xfconf/xfconf-cache.c
Commit message (Collapse)AuthorAgeFilesLines
* Replace GTimeVal with gint64 epoch timeYongha Hwang2022-02-281-3/+3
|
* Remove GLIB_CHECK_VERSION IFDEFs which are obsolete after glib bumpAlexander Schwinn2020-12-151-18/+0
| | | Current glib minimum is 2.50.0
* xfconf-cache: Fix access to freed data (#16)cryptogopher2020-11-061-20/+30
| | | | | | | | | | | | | The code was based on false assumption that cancelling cancellable of asynchronous request stops execution of callback handler. In fact cancelling asynchronous call does not prevent callback from geting invoked. Moreover handlers for asynchronuos call are only invoked from thread's main loop. That means if you set property, then free cache you will have outstanding handler invocations with dangling pointers to XfconfCacheOldItem and no reliable way of detecting this situation inside handler. The solution is to only free old_item(s) inside handler and differentiate processing inside handler based on whether call has been cancelled (by checking cancellable status).
* Add support for GObject introspection and valaOlivier Duchateau2019-06-241-7/+10
| | | | - Fix bug #15135
* Fix compiler error -Wcast-function-type (GCC 8)Andre Miranda2019-04-151-1/+1
|
* Fix a path in xfconf_cache_set where the cache mutex isn't locked.Ali Abdallah2017-08-291-0/+1
|
* When multiple calls are made for the same property, it's possible that ↵Stefan Berzl2017-08-291-3/+14
| | | | | | | | xfconf_cache_set may be called twice before xfconf_cache_set_property_reply_handler, in which case old_item gets freed and the second handler call might cause undefined behavior or a segfault. Added a counter to prevent that. Signed-off-by: Ali Abdallah <ali@xfce.org>
* Don't free up GValue as its ownership is taken by a cache item.Ali Abdallah2017-06-231-8/+7
|
* Fix many issues with libxfconf.Ali Abdallah2016-05-271-50/+118
| | | | | GPtrArray is now duplicated and saved in the cache, so the user can free the return array value.
* Fix a couple of memory leaks, due to g_variant conversion floatingAli Abdallah2016-04-251-24/+29
| | | | references.
* Use gvalue<->gvariant conversion functions from the commonAli Abdallah2016-04-241-87/+8
| | | | | | xfconf-gvaluefuncs.c code. Change XfconfClient to XfconfExported according to the dbus xml file.
* Move the gdbus generated code to the common directoryAli Abdallah2016-04-211-1/+1
|
* Port xfconf_channel_get_properties to gdbus andAli Abdallah2016-04-211-4/+4
| | | | Get rid of the last dbus-glib code in libxfconf.
* Port the call 'set_property' to gdbus.Ali Abdallah2016-04-211-46/+125
| | | | | | The XFCONF_TYPE_G_VALUE_ARRAY old dbus-glib type is not used anymore. Instead the G_TYPE_PTR_ARRAY type is used and then each value of the array is converted to GVariant before sending over dbus.
* Port xfconf_channel_get_arrayv to gdbus. Now the function worksAli Abdallah2016-02-151-22/+20
| | | | | | | as follows: xfconf_channel_get_internal is called to get a GValue which should contain a GVariant that is an array of variants value. Each of these GVariant value is transformed to a GValue and added to the GPtrArray.
* Port some cache lookup function of libxfconf to gdbus.Ali Abdallah2016-02-041-19/+14
|
* Replace the DBusGProxy signals handler with theirAli Abdallah2015-11-021-67/+83
| | | | GDBusProxy equivalents. All the rest is still based on DBusGProxy.
* Use new glib 2.32 mutex api.Nick Schermer2012-11-071-27/+43
|
* Updates for release.xfconf-4.10.0Nick Schermer2012-04-281-4/+2
|
* Don't emit property-changed on cancelled calls.Nick Schermer2012-04-221-0/+7
|
* Fix double free crash (bug #8169).Olivier Fourdan2011-12-201-4/+4
| | | | | | | | | | | In xfconf_cache_set_property_reply_handler() if the item is not found in cache->properties, the function exit (goto out;) without removing the old_property from cache->old_properties nor the call from cache->pending_calls. Then when xfconf_cache_set() is called, the old_item is still found in the hash (as it wasn't removed previously) and therefore dbus_g_proxy_cancel_call() is called in a call which was completed, thus leading to the double-free and the crash.
* Cleanup includes.Nick Schermer2011-05-261-3/+3
|
* Fix licenses and use new FSF address.Nick Schermer2011-03-251-8/+9
|
* The last used timestamp is not used yet, disable it.Nick Schermer2010-02-101-0/+8
|
* Don't look for existing keys during prefetch.Nick Schermer2010-02-101-11/+6
| | | | | | Since each channel has its own cache, we can avoid updating values because the hash table contains unique properties and there are no nodes in the tree yet.
* Steal values from the hash table on prefetch.Nick Schermer2010-02-101-29/+36
|
* Mark the signal name as a static string.Nick Schermer2010-02-091-2/+2
|
* Disable the max-age and max-entries cache props.Nick Schermer2010-02-091-5/+14
| | | | | Both are not implemented yet, so disable them until we actually use it.
* Don't use cache singletons.Nick Schermer2010-02-091-44/+4
| | | | | | | | | | | None of the Xfce apps opens more then 2 new channels with the same name, so that means we never return an existing cache object and use it twice. It also leaked the hash table for the cache singletons, so optimize for the 'common case'. 2 of the same caches works fine (but doubles the dbus traffic) so to really fix this an app should use the channel singletons. Mentioned this in the API docs.
* Destroy hash table after prefetching the cache.Nick Schermer2010-02-081-0/+1
|
* Only print debug messages when compiled with debugging.Nick Schermer2010-01-251-0/+4
|
* Fix ansi compiler warning.Nick Schermer2010-01-201-4/+6
|
* Fix typo in comment.Nick Schermer2009-12-291-1/+1
|
* Wait for pending calls in the cache.Nick Schermer2009-12-291-9/+43
| | | | | | | | | | | Brian already added a FIXME with the question if we should wait for pending calls to finish before freeing the items. Well the question is yes, because the get-tests failed on my system because the channel was closed in the set-tests before dbus replied and thus nothing was stored in the test-channel. So wait for pending calls in finalize and skip the normal reply handler by setting the hash table in the cache to NULL.
* Fix segfault triggered by object-bindings test.Nick Schermer2009-12-261-1/+4
| | | | | | | | | | | | | | It turned out the object bindings code triggered a bug in the cache code because it edits multiple properties with the same name in a short time and then destroying the channel. This left a number (6) of pending call keys in one of the hash tables with the same value resulting in double frees when destroying the table. To fix this steal the item from the table when cancelling the dbus call, then the old_item we insert again is then not freed and exists only once in the table.
* Fix double free.Nick Schermer2009-12-261-2/+1
| | | | | | When leaving the reply handler xfconf should only remove the mutex lock and not free the item since we only looked it up from the hash table, it's not stolen yet.
* Make 2 critical warnings debug output.Nick Schermer2009-12-261-2/+2
| | | | | | Those 2 warnings are always shown when removing an xfconf property that does not exist. This makes applications abort that use g_log_set_always_fatal().
* pass correct parameters to XfconfCache::property-changed signalBrian J. Tarricone2009-09-181-2/+2
|
* make xfconf_cache_reset() syncBrian J. Tarricone2009-09-181-2/+74
| | | | | | this is unfortunate, but it's very hard to keep the cache consistent when doing this async. there are also problems with calls to xfconf_channel_has_property() right after resetting a property.
* pass correct key to g_tree_remove()Brian J. Tarricone2009-09-181-1/+1
|
* emit proper arguments on XfconfCache::property-changed signal (bug 5734)Brian J. Tarricone2009-09-041-4/+3
| | | | | | that's what happens when you copy and paste and don't change the arguments. also remove the G_SIGNAL_DETAILED flag for property-changed since we don't really need it for XfconfCache (just for XfconfChannel).
* fix detection of channel/property not found error when setting propsBrian J. Tarricone2009-08-231-3/+18
| | | | | | | | | | | dbus-glib's GError registration/mapping is crap. instead of doing something actually useful and mapping the error returned by dbus (e.g. "org.xfce.Xfconf.Error.PropertyNotFound") back into the correct GError domain (XFCONF_ERROR) and GError code (XFCONF_ERROR_PROPERTY_NOT_FOUND), it instead uselessly uses DBUS_GERROR and DBUS_GERROR_REMOTE_EXCEPTION, and then tacks the raw error string onto the end of GError::message, "hiding" it with a NUL byte. useless.
* fix crash; g_propagate_error() doesn't copy the src errorBrian J. Tarricone2009-08-231-1/+0
| | | | ... so we can't free it afterwards, obviously
* fix a possible reentrancy issue.Brian Tarricone2009-07-291-4/+6
| | | | | | | | a client could re-enter the set function when handling the signal that reverts a property value after an error. if the old_item is still in one of the hash tables, that could confuse things. (Old svn revision: 30419)
* add transparent property prefetching and cachingBrian Tarricone2009-07-291-0/+844
XfconfCache is a transparent cache that sits behind XfconfChannel, and, so far, involves no new API. this moves most of the dbus code from XfconfChannel to XfconfCache. on creation, XfconfChannel gets an XfconfCache object for that channel (the cache objects are per-channel-name singletons, regardless of property_base or whether or not the XfconfChannel is a singleton). on creation, XfconfChannel prefetches all properties in the channel. this might turn out to be a bad idea for large channels. property setting does not block if the setting is already in the cache. i may change this in the future to not block at all ever, but that might make reporting certain kinds of errors impossible. property resets are completely non-blocking. lookups are non-blocking if the setting is already in the cache. the cache automatically updates itself if another application modifies a property. the cache has hooks to set the maximum age of entries (in seconds) and the max number of entries to store in the cache. currently these two are unimplemented, and i'm not sure if there's value to exposing these in the public API. (Old svn revision: 30417)
View Lorry Controller Status