summaryrefslogtreecommitdiff
path: root/engine
Commit message (Collapse)AuthorAgeFilesLines
...
* docs/comments: make some corrections/updatesRyan Lortie2013-02-111-3/+3
| | | | | Many fixes for typos but also some adjustments for the recent refactoring (particularly updating HACKING).
* engine: accept out-of-order error reply messagesRyan Lortie2013-01-241-3/+20
| | | | | | | | | | | | | | | Due to a quirk of the implementation of the D-Bus daemon (see upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=59780 for details) error messages can arrive out of sequence with repsect to the order of the method calls that they are in reply to. This may or may not be a violation of the strict-ordering principle of D-Bus (which does not actually appear to be written into the spec) but either way, we should dial down our assumptions about ordering since the D-Bus implementation that everyone is using does not currently work this way. https://bugzilla.gnome.org/show_bug.cgi?id=687120
* engine: only Init the service when neededRyan Lortie2013-01-111-3/+7
| | | | | Instead of calling Init() blindly on startup for any service-db, only do it if the file is missing when we go to open it.
* engine: add a new database type: "service-db"Ryan Lortie2013-01-094-1/+94
| | | | | | | | | | | | | | service-db databases are based on a gvdb in the user runtime dir maintained by the dconf-service. On startup, the client will send an Init message to the service to ensure that the database is properly initialised. After that, things are pretty much the same except that the values are read from the file in the runtime dir instead of from the home directory. We also drop the "shm" signalling mechanism for this case and instead use the same invalidation trick that system databases use (ie: overwriting the old gvdb header after writing the new file).
* adjust to new gvdb APIsRyan Lortie2012-11-091-4/+4
|
* engine/: drop DConfChangesetListRyan Lortie2012-10-024-45/+6
| | | | | | It's really just a GQueue... https://bugzilla.gnome.org/show_bug.cgi?id=685316
* engine: improve robustness of profile parsingRyan Lortie2012-07-192-20/+43
| | | | | | | | | Checking for 'u' or 's' is really insanely silly from a robustness standpoint. Ensure that we properly have "user-db:" or "system-db:" and that a non-empty database name is given, warning if not. This was specifically causing annoying problems with the profile file that gdm was installing, so add a copy of that file to our testcases.
* engine: fix dconf_engine_list() with empty dbRyan Lortie2012-07-151-0/+3
| | | | | | | | If we opened an empty database file (like on first login) and did a 'dconf list' on it then we would crash (due to accessing the GVDB without checking for NULL). Add a check.
* engine: bring back origin_tag logicRyan Lortie2012-07-152-6/+10
| | | | | | | | | The GSettings backend still wants to use this and it does us no harm to have it on the engine API (which is only visible internally). Adjust the various consumers of the engine to the new API. Thanks to Rui Matos for reminding me about this...
* engine: fix arguments in fast watch race caseRyan Lortie2012-07-151-1/+3
| | | | | | In the case we do a fast watch and hit the race condition of a change occuring before our watch is established we need to emit a change signal on "/". The arguments for that were incorrect, so fix them.
* engine/: don't check for writability on resetRyan Lortie2012-07-121-1/+4
| | | | | Resetting keys should absolutely always succeed, so don't check for key writability in that case.
* DConfEngineSource: return FALSE from NULL refreshRyan Lortie2012-07-121-1/+14
| | | | | | | | | | In the case that we call dconf_engine_source_refresh() on a source that had a NULL database and the result is that we still have a NULL database, return FALSE. This will prevent the unnecessary bumping of the state counter when there was really no change. This happens in the case of a missing system database file.
* DConfEngineSource: remove the external init callRyan Lortie2012-07-123-13/+2
| | | | | Always do init as part of the process of dconf_engine_source_new() to avoid the consumer from having to call it for themselves.
* DConfEngineUserSource: don't open on initRyan Lortie2012-07-121-5/+0
| | | | | Don't open the database file on _init(). This makes us match the system source better.
* engine/: source init can never failRyan Lortie2012-07-125-12/+7
| | | | | Stop returning a boolean here (since all of the sources always returned TRUE all the time anyway).
* engine/: fix refcounting errorRyan Lortie2012-07-121-1/+1
| | | | | | | | | | | The new supposedly-threadsafe implementation of refcounting in the engine still had a bug in it: in the event that we were going to remove the last reference and we discovered that the refcount was not 1 after taking the lock, we would return (under the assumption that someone else had increased the count). This is the wrong thing to do. No matter what, we need to drop our reference -- instead of return, we should goto again.
* Remove workaround for GCC's obnoxious behaviourRyan Lortie2012-07-111-7/+2
| | | | The workaround is in GLib now, so we don't have to do it.
* dbus test: add function to initialise for testingRyan Lortie2012-07-111-0/+2
| | | | | | | We were hardcoding g_type_init() in the D-Bus testcase because the GDBus backend depended on that happening. That is not true for the libdbus-1 backend, so split it out into a separate function implemeneted by the backend.
* engine: add dconf_call_handle_get_expected_type()Ryan Lortie2012-07-112-0/+8
| | | | | | We were storing the expected type of the reply in the call handle already but not really doing anything with it. Provide an API to access it.
* Reimplement sync() functionalityRyan Lortie2012-07-102-1/+42
| | | | | | | | | Add dconf_engine_sync() that does the same thing as the code in the GSettings backend used to do, in a cleaner way. Update the GSettings backend to use the new call. Add a new call to DConfClient wrapping the engine call as well.
* engine: fix dconf_engine_unref() thread safetyRyan Lortie2012-07-101-31/+17
| | | | | | | | | | | | | | | | | | | | | | | There was a very slim race condition in the implementation of dconf_engine_unref(). In order to check if the engine should be freed (to avoid double-freeing in two separate threads) the code was checking if the engine was still in the global list of engines. It is possible, however, that this thread could have unrefed the engine at exactly the same time as another thread, that thread won the race and freed the engine (removing it from the list) and then a third thread created another engine at the same time and it happened to have the same pointer address as the engine that was just freed. In this case, the first engine would still see "itself" in the global list and free again. It's unlikely that this would ever happen in the real world but the regression tests picked it up. The new implementation should avoid that issue by not depending on the engine finding itself in the list as part of the decision about if it should be freed or not.
* clean up C compiler warningsRyan Lortie2012-07-081-1/+1
| | | | | | | Disable C compiler warnings entirely while building Vala code. Fix-up a couple of legitimate issues plus one false-positive (in service.c).
* massive Makefile reorganisationRyan Lortie2012-07-086-9/+10
| | | | | | | | | | Clean up the Makefiles and make them as similar as possible. Move CFLAGS to a common point of definition and stop using -I so much. Replace the 'dbus stub' with libdconf-mock.a in tests/. Fill in some stubs for future mock code for shm and gvdb (just to get things compiling for now).
* user source: change approach to shmRyan Lortie2012-07-081-12/+3
| | | | | | | | | | Use dconf_shm_is_flagged() instead of direct access. Change the semantics of what happens when we fail to open the shm file. We used to refuse to initialise at all in that case -- now we initialise but will try again every time to reopen ourselves. The error case will now be slower but closer to the correct behaviour.
* clean up and factor out the 'shm' codeRyan Lortie2012-07-082-57/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the shm code from the engine and the service and put it in a separate convenience library in shm/. Remove the vestigial shmdir weirdness from the service (since shmdir is now always relative to XDG_RUNTIME_DIR and has been for some time). The purpose of this is so that dconf-engine can be properly unit-tested. dconf-engine now has five points of contact with the world (excluding the users of the engine themselves): - the DCONF_PROFILE environment variable - fopen() of profile files - shm - gvdb - dbus The environment variable is quite easily controlled. fopen() is intercepted in the engine testcase with a interpose of the libc symbol. With this commit now each of dbus, gvdb and shm are implemented in separate utility modules that can be mocked from the testcases.
* engine/: mark some structs 'extern' in a headerRyan Lortie2012-07-081-2/+2
| | | | | | | | | | | | This should have been done in the first place but it went unnoticed because the linker has an odd habit of permitting two structs with the same name to be defined. It only became a problem when optimisation was turned on and GCC noticed that nobody was writing to one particular copy of that struct and assumed that its contents would always be all-zeros (which is an assumption that later became untrue once the linker had done its strange magic).
* profile parser: firm up and document semanticsRyan Lortie2012-07-085-31/+126
| | | | | | | | | Clean up the profile parser, firming up the semantics of exactly what happens in all cases. Document it. There are now no more cases of aborting due to failures caused while opening, parsing or initialising the profile. Lines of arbitrary length are also supported.
* sources: don't leak bus name and object pathRyan Lortie2012-07-061-0/+2
| | | | On finalize, we weren't freeing these properly.
* user source: use threadsafe init for shmdirRyan Lortie2012-07-061-2/+2
| | | | | | | | Otherwise it's possible for multiple threads to initialise it at the same time. Each thread will come up with the same value anyway, but it's a string, so we will leak all but one of them.
* fix various 'make distcheck' issuesRyan Lortie2012-07-061-1/+3
|
* engine: fixup parameters order for change callbackRyan Lortie2012-07-061-1/+1
|
* engine: allow for NULL value tablesRyan Lortie2012-07-061-3/+8
| | | | | This will happen for user databases if the database has never written to (ie: first login to fresh user account).
* engine: correct logic error in queue checkingRyan Lortie2012-07-061-1/+1
| | | | | | | The logic used for checking for changes in the pending and in-flight queues was backwards meaning that the in-flight queue was only checked if a match was found in the pending queue. We rather want the in-flight queue to be checked only if we have not found a match already.
* dconf source abstraction: don't leak the GVDBsRyan Lortie2012-07-061-0/+6
| | | | | | On finalize, the GVDBs associated with a source weren't being freed. This means that freeing a DConfClient (or any other DConfEngine user) would result in leaking of GVDBs.
* profile parser: return number of sourcesRyan Lortie2012-07-061-0/+2
| | | | The profile parser wasn't setting the n_sources out variable.
* profile parser: handle newline characters properlyRyan Lortie2012-07-061-1/+3
| | | | | The profile parser wasn't chopping newlines from the configuration file which resulted in creation of filenames like "user\n".
* .gitignore for common/, gdbus/ and engine/Ryan Lortie2012-07-061-0/+1
|
* add gtester supportRyan Lortie2012-07-061-0/+2
|
* Implement change signalsRyan Lortie2012-07-022-16/+142
| | | | | | | | | | | | | | | | Support receiving and properly exposing change notifications. This required some changes to improve the thread-safety of destroying a DConfEngine. It is possible that a signal would be arriving (in the worker thread) at the exact instant that a DConfEngine was being destroyed (from the finalize of the DConfClient or DConfSettingsBackend). This could lead to the object being accessed after it was finalized. We can avoid this by using weak references and by being more careful about when the DConfEngine is freed (by taking a ref to it in the signal handler and releasing it when done).
* Massively reorganise the client-sideRyan Lortie2012-07-0211-623/+1535
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit represents a rather complete rethinking of DConfEngine. - the different kinds of sources are now properly abstracted. This will make landing NFS support substantially easier. - there is now substantially more internal documentation - DConfEngineMessage is gone and replaced with ordinary function calls to be implemented by the D-Bus glue code - the GDBus glue has been factored out and is now shared between the client library and GSettings - the "outstanding" queue logic from the GSettings backend is now in the engine - all changes now go through a single API that accepts a (new) DConfChangeset object. Currently this only supports the current operations (ie: setting and resetting). In the future this object will also support the directory operations required by GSettingsList and will be the basis for the new approach to implementing the 'delayed' GSettingsBackend (which will be the method by which those two concepts can co-exist). The (internal) API of the engine changed substantially. This caused the following: - the libdconf client library has been rewritten in C. Most of the complicated aspects of it (that made it more convenience to use Vala) are now gone. - during the rewrite of libdconf, the DConfClient API changed a bit to look more like a proper GObject. It now makes GIO-style use of thread-default main contexts and uses GObject signals for notifications (instead of hand-rolled callbacks). - the GSettings backend has been substantially simplified (the "outstanding" logic is gone). No externally-visible changes. - the dbus-1 backend has taken a copy of the old engine code for now until it can be ported to the new engine and sufficiently tested. No externally-visible changes. - the dconf commandline tool and dconf-editor required minor changes to adjust to the DConfClient API changes There is a substantial amount of cleaning up and finishing of work to be done. There are many stubs remaining. There are likely still a large number of bugs.
* dconf engine: don't leak lock table on reloadRyan Lortie2012-03-191-0/+6
| | | | | | If the system database changes while a program is running make sure we unref the old copy of the lock table (if it exists) before trying to load the new one.
* engine: free multiple 'shm' properlyRyan Lortie2012-03-061-4/+4
| | | | | In case of multiple user databases, we need to unref multiple 'shm' mappings.
* engine: allow multiple user databasesRyan Lortie2012-03-031-61/+95
| | | | | | | Drop the long-standing assumption that there will be exactly one user database. https://bugzilla.gnome.org/show_bug.cgi?id=662438
* engine: support absolute paths in DCONF_PROFILERyan Lortie2012-03-031-1/+6
|
* engine: drop some dead filesRyan Lortie2012-02-056-42/+0
|
* engine: fix checking for locksRyan Lortie2012-02-031-1/+1
| | | | | | | | | | | | | The algorithm that checked for locks essentially answers the question of "what is the highest level database that we should consider results from?". In the case of only one database, its answer to this question could be out of range of the set of databases that we asked it to search in. Correct this problem by bounding the starting point of the search accordingly. Reported by Didier Roche.
* drop unused dconf_engine_interpret_reply()Ryan Lortie2011-10-192-19/+0
|
* Stop using deprecated GLib APIsRyan Lortie2011-10-191-11/+11
|
* Remove "service func" logicRyan Lortie2011-09-112-54/+1
| | | | | | This was required to support the case where the dconf client was unable to determine the cache directory for itself. Since we now use the XDG runtime directory, this is redundant.
* Remove 'set lock' support from dconfRyan Lortie2011-09-112-15/+0
| | | | | | | | | | | | | | | | | | The dconf service can not presently be run at the system level and it doesn't make sense to support locks on user-level databases. It also became clear that most distributors and sysadmins would rather work directly with text files anyway, so we supported that directly instead. For this reason, 'set lock' support has never been properly implemented. All the plumbing was added for it though, which means we have it appearing on the API of the client library and documented in the help of the commandline tool. This is misleading, since these functions do nothing at all (and actually contain bugs anyway since their do-nothingness was never actually tested). For now, we rip out these functions. We can add them back later if we decide to support this properly.
View Lorry Controller Status