If the fd is not a pipe or socket, fall back to using threads to do
async I/O rather than poll, since poll doesn't work the way you want
for ordinary files.
https://bugzilla.gnome.org/show_bug.cgi?id=606913
My previous fix for GNOME#662100 was incomplete: it seems that with some
timings, the stream can be closed with an async read in-flight. This
can make the read fail immediately with G_IO_ERROR_CLOSED instead of
becoming cancelled.
This happens reliably on an embedded device, and rarely on my laptop;
repeating the test 100 times in quick succession reliably reproduces
the bug on my laptop.
It seems as though what we really want is to ignore read errors, once
we've established that we want to close the connection anyway - this
means that after asking to close, you're immune to exit-on-close,
which seems like a good rule.
An additional subtlety is that continuing to read after we know we
want to close is still required, otherwise we'll never emit ::closed.
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: Colin Walters <walters@verbum.org>
Similar to G_PARAM_DEPRECATED. It will warn only for users of the
signals, so a signal can still be emited without warning, for
compatibility reasons.
Apparently, there is no way user flags could have been used before,
so that shouldn't break anyone.
https://bugzilla.gnome.org/show_bug.cgi?id=663581
Instead of:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use '((GType) ((21) << (2)))' instead [-Wdeprecated-declarations]
show:
warning: ‘g_variant_get_gtype’ is deprecated (declared at ../../gobject/glib-types.h:242): Use ''G_VARIANT_GET_TYPE'' instead [-Wdeprecated-declarations]
Also, document the macro-expansion problem in the
G_GNUC_DEPRECATED_FOR docs
Allow passing --identifier-prefix and --symbol-prefix to glib-mkenums,
with the same meanings as in g-ir-scanner, to allow fixing up the enum
name parsing globally rather than needing to add a /<* *>/ override to
each enum.
https://bugzilla.gnome.org/show_bug.cgi?id=661797
If the GDBusObjectManagerClient doesn't get a name owner during its lifetime,
`on_control_proxy_g_signal' will never be connected to any signal, so we
shouldn't dump any warning in that case.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=662858
"make tags" is the best way to produce tags in an automake project and
yet very few people are using it so the tags files it generates are never
added to the .gitignore files.
Add TAGS files to .gitignore then.
https://bugzilla.gnome.org/show_bug.cgi?id=615424
Any flags specified as well as "all" are subtracted from the result,
allowing the user to specify FOO_DEBUG="all,bar,baz" to mean "give me
debugging information for everything except bar and baz".
https://bugzilla.gnome.org/show_bug.cgi?id=642452
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>
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>
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>
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>
