summaryrefslogtreecommitdiff
path: root/testgdate.c
diff options
context:
space:
mode:
authorSimon McVittie <simon.mcvittie@collabora.co.uk>2011-10-21 15:46:00 +0100
committerSimon McVittie <simon.mcvittie@collabora.co.uk>2011-10-24 10:40:26 +0100
commita031bacaac77d5de7388203dbe1ccc67b9142482 (patch)
tree349f86c0ffe9458cbbf22bd1e3345345859ff94f /testgdate.c
parent9857cf8c46511b0fb1ed60ea96da8f4a310263e5 (diff)
GDBusConnection: make the closed flag atomic (but still lock to write)
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>
Diffstat (limited to 'testgdate.c')
0 files changed, 0 insertions, 0 deletions