GDBusConnection: make the closed flag atomic (but still lock to write)
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Fri, 21 Oct 2011 14:46:00 +0000 (15:46 +0100)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 24 Oct 2011 09:40:26 +0000 (10:40 +0100)
commita031bacaac77d5de7388203dbe1ccc67b9142482
tree349f86c0ffe9458cbbf22bd1e3345345859ff94f
parent9857cf8c46511b0fb1ed60ea96da8f4a310263e5
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>
gio/gdbusconnection.c