diff options
author | Simon McVittie <simon.mcvittie@collabora.co.uk> | 2011-10-21 15:46:00 +0100 |
---|---|---|
committer | Simon McVittie <simon.mcvittie@collabora.co.uk> | 2011-10-24 10:40:26 +0100 |
commit | a031bacaac77d5de7388203dbe1ccc67b9142482 (patch) | |
tree | 349f86c0ffe9458cbbf22bd1e3345345859ff94f /testgdate.c | |
parent | 9857cf8c46511b0fb1ed60ea96da8f4a310263e5 (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