Commit Graph

159 Commits

Author SHA1 Message Date
Ryan Lortie
cb4469600c GDBusConnection: be more careful with async GetAll
It's possible to get a org.freedesktop.Properties.GetAll call even if we
have no readable properties in the introspection, in which case we
should return the empty list in the usual way.

We should certainly _not_ be dispatching to the method call handler of
an interface which has no properties (since it will not be expecting
this).

Add a check to make sure that there is at least one readable property
before assuming that a NULL get_property handler implies that we want to
handle properties asynchronously.

Add a testcase that was failing before the change and works after it.

https://bugzilla.gnome.org/show_bug.cgi?id=703437
2013-07-01 23:36:30 -04:00
Ryan Lortie
f754c4e85b GDBusConnection: allow async property handling
The existing advice in the documentation to "simply" register the
"org.freedesktop.DBus.Properties" interface if you want to handle
properties asynchronously is pretty unreasonable.  If you want to handle
this interface you have to deal with all properties for all interfaces
on the path, and you have to do all of the checking for yourself.  You
also have to provide your own introspection data.

Introduce a new convention for dealing with properties asynchronously.

If the user provides NULL for their get_property() or set_property()
functions in the vtable and has properties registered then the
properties are sent to the method_call() handler.  We get lucky here
that this function takes an "interface_name" parameter that we can set
to "org.freedesktop.DBus.Properties".

We also do the user the favour of setting the GDBusPropertyInfo on the
GDBusMethodInvocation for their convenience (for much the same reasons
as they might want the already-available GDBusMethodInfo).

Add a testcase as well as a bunch of documentation about this new
feature.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
2013-06-22 13:38:31 -04:00
Ryan Lortie
c691f7b6ca GDBusMethodInvocation: add 'property_info'
Add a field on GDBusMethodInvocation for GDBusPropertyInfo.

For now, it is always %NULL.  It will be set in future patches.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
2013-06-22 13:38:31 -04:00
Ryan Lortie
14dc028003 GDBusConnection: some straight-up refactoring
Separate the code for validating a method call from the code for
actually scheduling it for dispatch.

This will allow property Get/Set/GetAll calls to be dispatched to the
method_call handler without duplicating a lot of code.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
2013-06-22 13:38:30 -04:00
Ryan Lortie
02f5cdd983 GDBusConnection: move 'Set' typecheck to worker
We presently do a lot of checks on property sets (signature check,
correct interface, property exists, etc.) from the worker thread before
dispatching the call to the user's thread.  The typecheck, however, is
saved until just before calling the user's vfunc, in their thread.

My best guess is that this was done to save having to unpack the value
from the tuple twice (since we don't unpack it until we're just about
the call the user).

This patch moves the check to the same place as all of the other checks.

The purpose of this change is to allow for sharing this check with the
(soon-to-be-introduced) case of handing property sets from
method_call().

This change has a minor side effect: error messages generated by sending
invalid values to property sets are no longer guaranteed to be correctly
ordered with respect to the void returns from successful property sets.
They will instead be correctly ordered with respect to the other error
messages.

https://bugzilla.gnome.org/show_bug.cgi?id=698375
2013-06-22 13:37:54 -04:00
Ryan Lortie
0d29b17af7 GDBusConnection: remove an unused g_variant_get()
https://bugzilla.gnome.org/show_bug.cgi?id=698375
2013-06-22 13:36:51 -04:00
Dan Winship
4b94c0831e Use 'dumb quotes' rather than `really dumb quotes'
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.

However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.

Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.

Fix this by just using 'dumb quotes' everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=700746
2013-05-21 11:23:22 -03:00
Lars Uebernickel
00f6d78125 g_dbus_connection_signal_subscribe: add path and namespace matching
https://bugzilla.gnome.org/show_bug.cgi?id=695156
2013-04-08 15:59:39 +02:00
Thomas Bechtold
c9a3cd6d8b Fix gdbus connection annotations
g_dbus_connection_call_with_unix_fd_list_sync () and
g_dbus_connection_call_sync () should allow None for the
bus_name parameter.

https://bugzilla.gnome.org/show_bug.cgi?id=683771

Signed-off-by: Richard Hughes <richard@hughsie.com>
2012-09-11 13:16:32 +01:00
Phil Clayton
02eed18a4e Add missing annotation to GDBusConnection::closed
Add annotation (allow-none) to the parameter error.

https://bugzilla.gnome.org/show_bug.cgi?id=677952
2012-06-23 17:54:33 -04:00
Tomas Bzatek
032e8dabd1 gdbus: Implement g_dbus_connection_get_last_serial()
This patch brings an ability to retrieve serial number of the last
message sent within the current thread.

https://bugzilla.gnome.org/show_bug.cgi?id=676825
2012-06-06 19:44:39 +02:00
Xavier Claessens
2e3d50631f Add private _g_bus_get_singleton_if_exists() function
This is used by g_test_dbus_down() to ensure the GDBusConnection
gets disposed, but not create one if the singleton already got
disposed.

https://bugzilla.gnome.org/show_bug.cgi?id=672985
2012-04-19 10:06:21 +02:00
David Zeuthen
26d4da2352 Revert "Add private _g_bus_get_singleton_if_exists() function"
This reverts commit f8a8e90398.
2012-04-18 13:48:09 -04:00
Xavier Claessens
f8a8e90398 Add private _g_bus_get_singleton_if_exists() function
This is used by g_test_dbus_down() to ensure the GDBusConnection
gets disposed, but not create one if the singleton already got
disposed.

https://bugzilla.gnome.org/show_bug.cgi?id=672985
2012-04-18 11:19:13 -04:00
David Zeuthen
ce81bd87c5 GDBusAuthObserver: Add a way to control what authentication mechanisms to use
This is related to https://bugzilla.gnome.org/show_bug.cgi?id=673943
but also useful in a lot of other contexts.
2012-04-14 11:52:20 -04:00
Robert Ancell
4143842eb4 Add missing allow-none annotations for function parameters.
Found using:
find . -name '*.c' | xargs grep 'or %NULL' | grep ' \* @' | grep -v '@error' | grep -v allow-none
2012-03-31 20:34:28 +11:00
Marco Trevisan (Treviño)
322c6e9344 GDBusConnection: Avoid dereferencing vtable for unregistered objects
https://bugzilla.gnome.org/show_bug.cgi?id=671988

Signed-off-by: David Zeuthen <davidz@redhat.com>
2012-03-19 17:12:00 -04:00
Ryan Lortie
2afbc425eb GDBus: set no-reply flag on calls with no callback
If g_dbus_connection_call() or g_dbus_proxy_call() are given a NULL
callback then set the no-reply flag on the outgoing D-Bus message.

https://bugzilla.gnome.org/show_bug.cgi?id=672239
2012-03-19 12:41:23 -04:00
David Zeuthen
f025c9c4f4 GDBusConnection: Don't store GCancellable in qdata
Now that we're using g_simple_async_result_set_check_cancellable() we
no longer need this terrible hack of carrying the GCancellable on the
GSimpleAsyncResult using qdata. See bug 672013 for more details.

https://bugzilla.gnome.org/show_bug.cgi?id=672013

Signed-off-by: David Zeuthen <davidz@redhat.com>
2012-03-15 14:04:39 -04:00
Ryan Lortie
e3c7fdd7a4 GDBus: make use of reliable async cancellation
Call g_simple_async_result_set_check_cancellable() after all
GSimpleAsyncResult creation in order to take advantage of the new
reliable cancellation feature.

The guarantee of reliable cancellation fixes a bug in dbusmenu (which
was already assuming that cancellation was reliable).  See this bug:
https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/953562

https://bugzilla.gnome.org/show_bug.cgi?id=672013

Signed-off-by: David Zeuthen <davidz@redhat.com>
2012-03-15 14:01:35 -04:00
David Zeuthen
7a4a973cfd GDBusConnection: Don't leak message reply in error path
This was reported in bug 670909.

https://bugzilla.gnome.org/show_bug.cgi?id=670909

Signed-off-by: David Zeuthen <davidz@redhat.com>
2012-02-27 14:53:13 -05:00
David King
8ee2cadd7f docs: Fix some GDBusConnection typos 2012-02-21 01:10:54 +01:00
Will Thompson
7a0bddd768 GDBusConnection: note that exit-on-close is sometimes TRUE
g_bus_get_finish() and g_bus_get_sync() both document that the returned
object will usually have exit-on-close set to TRUE, but the property's
documentation specified that its default is FALSE. While that's
technically true from a GObject perspective, it's not accurate from the
API user's perspective.

https://bugzilla.gnome.org/show_bug.cgi?id=668163

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <zeuthen@gmail.com>
2012-01-18 16:16:58 +00:00
Simon McVittie
1e09bfc77c GDBusConnection: use GWeakRef to make the singletons thread-safe
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=665211

https://bugzilla.gnome.org/show_bug.cgi?id=548954
2012-01-02 12:23:24 -05:00
David Zeuthen
70dacf83d2 Bug 665733 – GDBusConnection holds lock while calling destroynotify
Fix this problem by always running the destroynotify from an idle.

https://bugzilla.gnome.org/show_bug.cgi?id=665733

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-12-07 10:30:42 -05:00
Simon McVittie
83d0c8a739 GDBusConnection: propagate error correctly if flags are inappropriate
Previously, this would fail the assertion
"connection->initialization_error != NULL" after the label "out".

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=665067
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-12-05 18:15:19 +00:00
Simon McVittie
c4a11858cf GDBusConnection: don't pass boolean > 1 to _g_dbus_worker_new
This happens to work at the moment (because GDBusWorker.frozen is a
gboolean and not just a 1-bit bitfield), but isn't right: the gboolean
ends up with values 0 or G_DBUS_CONNECTION_FLAGS_DELAY_MESSAGE_PROCESSING
(which is more than 1).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664558
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-11-22 16:08:14 +00:00
Matthias Clasen
6c7387f6d1 Trivial doc typo fix 2011-11-19 16:23:33 -05:00
Simon McVittie
a124562d1b GDBusConnection: document that this object is (meant to be) thread-safe
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-24 10:40:29 +01:00
Simon McVittie
a031bacaac 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>
2011-10-24 10:40:26 +01:00
Simon McVittie
9857cf8c46 GDBusConnection: document which properties are protected by @lock
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-24 10:40:23 +01:00
Simon McVittie
8df114f597 GDBusConnection: access the exit-on-close flag atomically
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-24 10:40:20 +01:00
Simon McVittie
3a0b60647d Annotate GDBusConnection private functions with thread/lock status
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-24 10:40:06 +01:00
Simon McVittie
848df03e16 GDBusConnection: check for initializedness in most public API
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-21 16:02:33 +01:00
Simon McVittie
3958a9fc1e GDBusConnection: document use while uninitialized as undefined behaviour
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-21 16:02:31 +01:00
Simon McVittie
a7ea949294 GDBusConnection: check for initialization where needed for thread-safety
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-21 16:02:27 +01:00
Simon McVittie
245d68be6f GDBusConnection: replace is_initialized with an atomic flag
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-21 16:02:22 +01:00
Simon McVittie
a7143a0e9f GDBusConnection: warn that direct access to the stream is a bad idea
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661679
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2011-10-15 18:03:19 -04:00
David Zeuthen
3c4d3dec09 GDBusConnection: Make pending calls error when the connection is lost
If the connection to the bus is lost while a method call is ongoing,
the method call does not get cancelled. Instead it just sits around
until it times out.

This is visible here on XO laptops when stopping the display manager
during shutdown. imsettings starts sending a sync message to give up
its bus name (via g_bus_unown_name()), then systemd terminates the
session bus at approximately the same time. imsettings then hangs for
about 20 seconds before timing out the message.

 http://lists.freedesktop.org/archives/dbus/2011-September/014717.html

imsettings behaviour could be improved as described in that thread,
but I think this is a glib bug. I've also come up with the attached
patch which fixes it.

Credits for the bug-fix goes to Daniel Drake <dsd@laptop.org>. The test
case was written by David Zeuthen <zeuthen@gmail.com>.

https://bugzilla.gnome.org/show_bug.cgi?id=660637

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-10-07 14:23:03 -04:00
Dan Winship
59f1f54655 Add g_main_context_ref_thread_default()
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.

https://bugzilla.gnome.org/show_bug.cgi?id=660994
2011-10-07 10:14:34 -04:00
Ryan Lortie
5f48e2cde5 GDBus: switch to struct-embedded GMutex and GCond
Now that we have those, we should use them.

https://bugzilla.gnome.org/show_bug.cgi?id=660739
2011-10-04 11:13:46 -04:00
Simon McVittie
8097e2de85 GDBusConnection: delegate to the worker to close the stream
We can't safely close the output part of the I/O stream until any
pending write or flush has been completed. In the worst case, this could
lead to an assertion failure in the worker (when the close wins the
race) or not closing the stream at all (when the write wins the race).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
Matthias Clasen
1b28408b8b Spelling fixes
Spelling fixes in comments and docs, provided by
Kjartan Maraas in bug 657336.
2011-08-29 14:49:32 -04:00
Brian Cameron
b5f1ea4bb1 void functions should not return. Fixes bug #656675. 2011-08-17 03:01:14 -05:00
Martin Pitt
c783bfd4e7 [gi] Add missing (allow-none) annotations to g_dbus_connection_register_object() 2011-08-09 14:52:53 +02:00
David Zeuthen
659ba3d0b3 GDBusConnection: Only apply exit-on-closed semantics if properly initialized
Otherwise there is no point in gracefully handling the error...

https://bugzilla.gnome.org/show_bug.cgi?id=655664

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-08-01 11:58:05 -04:00
David Zeuthen
32b1349a23 More fixes for non-Unix builds
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-07-25 10:31:17 -04:00
David Zeuthen
f8b98841ad Fix the build on non-Unix
https://bugzilla.gnome.org/show_bug.cgi?id=655148

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-07-25 09:56:01 -04:00
Matthias Clasen
1f9e84896b Fix a typo 2011-07-23 21:07:48 -04:00
David Zeuthen
c404dbed11 gdbus-codegen: Add support for new org.gtk.GDBus.C.UnixFD annotation
Also add convenience _with_unix_fd_list variants to GDBusConnection,
GDBusProxy and GDBusMethodInvocation types to easily support this.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-07-21 16:06:18 -04:00