summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2011-10-24GDBusConnection: document that this object is (meant to be) thread-safeHEADmasterSimon McVittie1-0/+9
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-24GDBusConnection: make the closed flag atomic (but still lock to write)Simon McVittie1-67/+96
Strictly speaking, neither of the two uses that aren't under the lock *needs* to be atomic, but it seems better to be obviously correct (and we save another 4 bytes of struct). One of these uses is in g_dbus_connection_is_closed(), any use of which is inherently a race condition anyway. The other is g_dbus_connection_flush_sync, which as far as I can tell just needs a best-effort check, to not waste effort on a connection that has been closed for a while (but I could be wrong). I removed the check for the closed flag altogether in g_dbus_connection_send_message_with_reply_unlocked, because it turns out to be redundant with one in g_dbus_connection_send_message_unlocked, which is called immediately after. g_dbus_connection_close_sync held the lock to check the closed flag, which is no longer needed. As far as I can tell, the only reason why the lock is still desirable when setting the closed flag is so that remove_match_rule can't fail by racing with close notification from the worker thread - but on_worker_closed needs to hold the lock anyway, to deal with other data structures, so there's no point in trying to eliminate the requirement to hold the lock. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-24GDBusConnection: document which properties are protected by @lockSimon McVittie1-9/+16
Also, a few that don't need to be. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-24GDBusConnection: access the exit-on-close flag atomicallySimon McVittie1-7/+17
This isn't strictly necessary, because in every location where it's checked, if the reading thread misses an update from another thread, it's indistinguishable from the reading thread having been scheduled before the writing thread, which is an unavoidable race condition that callers need to cope with anyway. On the other hand, merging exit_on_close into atomic_flags gives the least astonishing semantics to library users and saves 4 bytes of struct, and if you're accessing exit-on-close often enough for it to be a performance concern, you're probably doing it wrong. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-24Annotate GDBusConnection private functions with thread/lock statusSimon McVittie1-26/+63
The thread shared between all GDBusWorker instances was variously called the "worker thread" or "message handler thread", which I mostly changed to "the GDBusWorker thread" to avoid ambiguity. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-22Updated Hebrew translation.Yaron Shahrabani1-1840/+1874
2011-10-21Updated Slovenian translationMatej Urbančič1-1545/+1550
2011-10-21GDBusMessage: fix leak of GErrorRyan Lortie1-1/+1
As part of the deserialisation process of a zero-length array in the DBus wire format, parse_value_from_blob() recursively calls itself with the expectation of failing (as can be seen by the assert immediately following). It passes &local_error to this always-failing call and then fails to free it (indeed, to use it at all). The result is that the GError is leaked. Fix it by passing in NULL instead, so that the GError is never created in the first place. https://bugzilla.gnome.org/show_bug.cgi?id=662411
2011-10-21GVariant format string docs: fix maybe typesRyan Lortie1-5/+6
The documentation for maybe types failed to mention 'a' as one of the types that was handled with a single pointer for which NULL means "nothing". Correct that omission. Problem caught by Shaun McCance.
2011-10-21Make g_ascii_strtod behave as documentedMatthias Clasen1-3/+5
The docs explicitly state that we reset errno, so lets do that, even if we just wrap strtod_l. Also move the argument check out of the ifdef. https://bugzilla.gnome.org/show_bug.cgi?id=662398
2011-10-21GDBusConnection: check for initializedness in most public APISimon McVittie1-0/+13
The only exceptions are those of the trivial getters/setters that don't already need the initialization check for its secondary role as a memory barrier (this is consistent with GSocket, where trivial getters/setters don't check): * g_dbus_connection_set_exit_on_close * g_dbus_connection_get_exit_on_close * g_dbus_connection_is_closed g_dbus_connection_set_exit_on_close needs to be safe for use before initialization anyway, so it can be set at construct-time. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-21GDBusConnection: document use while uninitialized as undefined behaviourSimon McVittie1-0/+16
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689 Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662208 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-21GDBusConnection: check for initialization where needed for thread-safetySimon McVittie2-8/+133
Also document which fields require such a check in order to have correct threading semantics. This usage doesn't matches the GInitable documentation, which suggests use of a GError - but using an uninitialized GDBusConnection is programming error, and not usefully recoverable. (The GInitable documentation may have been a mistake - GNOME#662208.) Also, not all of the places where we need it can raise a GError. The check serves a dual purpose: it turns a non-deterministic crash into a deterministic critical warning, and is also a memory barrier for thread-safety. All of these functions dereference or return fields that are meant to be protected by FLAG_INITIALIZED, so they could crash or return an undefined value to their caller without this, if called from a thread that isn't the one that called initable_init() (although I can't think of any way to do that without encountering a memory barrier, undefined behaviour, or a race condition that leads to undefined behaviour if the non-initializing thread wins the race). One exception is that initable_init() itself makes a synchronous call. We deal with that by passing new internal flags up the call stack, to reassure g_dbus_connection_send_message_unlocked() that it can go ahead. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689 Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-21GDBusConnection: replace is_initialized with an atomic flagSimon McVittie1-15/+29
The comment implied that even failed initialization would set is_initialized = TRUE, but this wasn't the case - failed initialization would only set initialization_error, and it was necessary to check both. It turns out the documented semantics are nicer than the implemented semantics, since this lets us use atomic operations, which are also memory barriers, to avoid needing separate memory barriers or locks for initialization_error (and other members that are read-only after construction). I expect to need more than one atomically-accessed flag to fix thread safety, so instead of a minimal implementation I've turned is_initialized into a flags word. Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661689 Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661992 Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-20Fix VS 2008 property sheetChun-wei Fan1-1/+1
Missed a required ';'-sorry about this. DOH! :|
2011-10-19Deprecate g_atexitMatthias Clasen2-1/+6
This function was just not a good idea to begin with. Its documentation gives plenty of reason not to use it.
2011-10-19desktop-app-info: annotate g_desktop_app_info_get_keywords()Cosimo Cecchi1-1/+1
https://bugzilla.gnome.org/show_bug.cgi?id=662096
2011-10-19more NEWS2.31.0Ryan Lortie1-1/+26
2011-10-19The usual docs unbreaking...Ryan Lortie5-6/+13
2011-10-19configure.ac: join the cargo-cult of _cv_Ryan Lortie1-4/+5
For some reason, the setting of g_atomic_lock_free wasn't making it down to the lower part of the configure script where glibconfig.h was being generated when building using mingw32-configure. If we prefix glib_cv_ to the start of the variable name (like everyone else is doing) then it magically starts working. I love you, automake.
2011-10-19gdbus-non-socket test: avoid use of a GMainContext across a forkSimon McVittie1-13/+38
See https://bugzilla.gnome.org/show_bug.cgi?id=658999 for why this would be bad. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-19gdbus-exit-on-close test: cover more possibilitiesSimon McVittie1-16/+125
We didn't previously test anything except the implicit default of TRUE. Now we test implicit TRUE, explicit TRUE, explicit FALSE, and disconnecting at the local end (which regressed while fixing Bug #651268). Also avoid some questionable use of a main context, which fell foul of Bug #658999 and caused this test to be disabled in master. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Bug-NB: NB#287088 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-19GDBusWorker: if a read was cancelled it means we closed the connectionSimon McVittie1-1/+11
This was a regression caused by my previous work on GDBusWorker thread-safety (Bug #651268). The symptom is that if you disconnect a GDBusConnection locally, the default implementation of GDBusConnection::closed terminates your process, even though it shouldn't do that for locally-closed connections; this is because GDBusWorker didn't think a cancelled read was a local close. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Bug-NB: NB#287088 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-19Revert "Disable two GDBus tests"Simon McVittie2-4/+2
This reverts commit 05ef173466e32d8b3d212803e4a72239913a362d. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100 Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-18Fix bug in g_static_rec_mutex_unlock_full()Ryan Lortie1-2/+5
pthreads doesn't implement the _lock_full() and _unlock_full() calls on recursive mutexes so we don't have it on GRecMutex either. Now that we're using GRecMutex to implement GStaticRecMutex, we have to fake it by keeping an internal counter of the number of locks and calling g_rec_mutex_unlock() the appropriate number of times. The code to do this looked like: depth = mutex->depth; while (mutex->depth--) g_rec_mutex_unlock (rm); return depth; which unfortunately did one last decrement after mutex->depth was already zero (leaving it equal to -1). When locked the next time, the count would then increase from -1 to 0 and then the next _unlock_full() call would not do any calls to g_rec_mutex_unlock(), leading to a deadlock. https://bugzilla.gnome.org/show_bug.cgi?id=661914
2011-10-18gatomic: introduce G_ATOMIC_LOCK_FREERyan Lortie6-54/+93
We clean up the detection of if we should do 'real' atomic operations or mutex-emulated ones with the introduction of a new (public) macro: G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to be done in hardware. We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our compiler supports GCC-style atomic operations from the gatomic.h header because we might be building a program against GLib using a different set of compiler options (or a different compiler) than was used to build GLib itself. Unfortunately, this macro is not available on clang, so it has currently regressed to using the mutex emulation. A bug about that has been opened here: http://llvm.org/bugs/show_bug.cgi?id=11174
2011-10-18gatomic: cast to the correct pointer signRyan Lortie1-3/+3
In the fallback case of the g_atomic_int_ macros we had some (gint*) casts that should have been (guint*) casts.
2011-10-18[l10n] Updated German translationMario Blättermann1-1666/+1670
2011-10-18gio: Introduce get_sort_key() methods on GDrive, GVolume and GMountDavid Zeuthen8-0/+96
This is needed to implement efficient and predictable proxy volume monitors, see https://bugzilla.gnome.org/show_bug.cgi?id=661711 for details. Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-10-18tests/gobject: Use G_VALUE_INITJavier Jardón1-5/+5
2011-10-18gobject: Use G_VALUE_INITJavier Jardón12-46/+46
2011-10-18gio: Use G_VALUE_INITJavier Jardón8-18/+18
2011-10-18GDBusConnection: Fix race in /gdbus/connection/life-cycleSjoerd Simons1-2/+1
GDBusConnection sets the closed flag in the worker thread, then adds an idle callback (which refs the Connection) to signal this in the main thread. The tests session_bus_down doesn't spin the mainloop, so the "closed" signal will always fire if iterating the mainloop later (and drops the ref when doing so). But _is_closed can return TRUE even before signalling this, in which case the "closed" signal isn't fired and the ref isn't dropped, causing the test to fail. Instead simply always wait for the closed signal, which is a good thing to check anyway and ensures the ref is closed. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896 Reviewed-by: Matthias Clasen <mclasen@redhat.com>
2011-10-18Actually Don't define GLIB_COMPILATION in libgthreadAlexander Larsson3-3/+11
Last commit was wrong, fixing it up
2011-10-18Don't define GLIB_COMPILATION in libgthreadAlexander Larsson2-11/+2
This was turning all the GLIB_VARs in the glib headers into dllexports on windows, causing all sort of nastiness. libgthread is mostly empty now anyway, so we don't need any GLIB_COMPILATION like flag.
2011-10-17Fix an include guard mismatchMatthias Clasen1-1/+1
Spotted by Colin Walters.
2011-10-17Fix up testcase broken due to g_thread_new API changeAlexander Larsson1-2/+2
2011-10-18Move _glib_get_locale_dir to ggettext.cChun-wei Fan2-50/+56
-Move _glib_get_locale_dir to ggettext.c, as Matthias suggested -Made up for the headers that needed to be included in ggettext.c to avoid C4013 (implicit declaration of ...) errors/warnings
2011-10-17Updated POTFILES.inPiotr Drąg1-20/+21
2011-10-17Fix gio.symbolsChun-wei Fan1-1/+0
g_simple_action_get_parameter_type is now static, so this symbol needs to be removed from here...
2011-10-17GLib: Add forgotten includes and build fixesChun-wei Fan4-0/+12
-gcharset.c, genviron.c, gunicollate.c: Some headers were missed in those files that triggered C4013 warnings/errors (aka. implicit declaration of ... in GCC). Make up for them here. -gwin32.h: Only define g_win32_get_package_installation_directory/ g_win32_get_package_installation_subdirectory as macros (alias of g_win32_get_package_installation_directory_utf8/ g_win32_get_package_installation_subdirectory_utf8) on Win64 (x64) as g_win32_get_package_installation_directory/ g_win32_get_package_installation_subdirectory have seperate existing implmentations for Win32-this is a long-standing problem but was covered- up by G_DISABLE_DEPRECATED, which we are stopping to use as of 2.31.0.
2011-10-17Revert "Bug 652827 - glib-2.29.8 no longer builds with mingw.org's toolchain"Ryan Lortie2-12/+2
This reverts commit 349212211247781e7bec43b95cb57dddc1d0e5b1.
2011-10-17Update VS property sheetsChun-wei Fan2-0/+15
Some new headers were added...
2011-10-17glib/tests/thread.c: Add config guardsChun-wei Fan1-0/+4
Not all systems come with unistd.h and sys/time.h, so use config guards on them so that they are only included when available.
2011-10-17Update VS property sheetsChun-wei Fan2-3/+3
gcache.h is now a deprecated header, so up the "install" part for it.
2011-10-17More include cleanupsMatthias Clasen4-7/+1
2011-10-17Update VS property sheetsChun-wei Fan2-2/+2
Stop using G_DISABLE_DEPRECATED as there are now warnings for usage of deprecated APIs/items in GLib
2011-10-17include cleanupMatthias Clasen1-4/+0
2011-10-17Make things compile againMatthias Clasen5-388/+5
2011-10-17Move gettext variations into their own filesMatthias Clasen2-0/+461
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-14 01:01:04 +0000