* Load modules from paths listed in GIO_EXTRA_MODULES environment
variable first.
* Ignore duplicate modules based on module basename.
* Add the concept of GIOModuleScope which allows other callers to
skip duplicate loaded modules, or block specific modules based on
basename.
* Document behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=656914
* Add cancellable argument to g_tls_interaction_ask_password
and g_tls_interaction_ask_password_async.
* This is API breakage, but this API has not yet been released
in a stable release (and very unlikely used yet).
* Since we're breaking unreleased API, expand amount of padding
on GTlsInteractionClass because we're going to need it.
https://bugzilla.gnome.org/show_bug.cgi?id=656443
Change the hardcoded /usr/bin/python shebag from gdbus-codegen.in into
@PYTHON@. Is used in Makefile.am to use detected python binary.
$(AM_V_GEN) sed -e 's,@libdir\@,$(libdir),' -e 's,@PYTHON\@,$(PYTHON),'
$< > $@.tmp && mv $@.tmp $@
Signed-off-by: Ionut Biru <ibiru@archlinux.org>
https://bugzilla.gnome.org/show_bug.cgi?id=657274
Rework property getters to use a vfunc so we can take the fast path
and avoid allocating memory for both the skeleton and the proxy
cases. This requires some special case because of how GVariant expects
you to free memory in some cases, see #657100. Add test cases for
this.
Document the _get_ functions as not being thread-safe and also
generate _dup_ C getters (which are thread-safe).
Mark all the generated _get_, _dup_ and _set_ as (skip) as non-C
languages should just use GObject properties and not the (socalled)
"C binding".
Signed-off-by: David Zeuthen <davidz@redhat.com>
The main rationale for adding it was to avoid having gnome-shell
mmap'ing /etc/localtime once a second. However, we can just as easily
run inotify there, and given no one else was clamoring for a way to
detect when the time zone changes, I don't see a need for public API
here - at least not yet.
In the bigger picture, I just don't believe that the vast majority of
applications are going to go out of their way to instantiate and keep
around a random GTimeZoneMonitor class. And if they do, it's has the
side effect that for other bits of code in the process, local GDateTime
instances may start varying again!
So, if code can't rely on local GDateTime instances being in a
consistent state anyways, let's just do that always. The
documentation now says that this is the case. Applications have
always been able to work in a consistent local time zone by
instantiating a zone and then using it for GDateTime constructors.
We fix the "gnome-shell stats /etc/localtime once a second" issue by
using timerfd (in glib) and inotify (in gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=655129
* Update documentation to note that GCancellable can be used
concurrently by multiple operations.
* Add documentation to g_cancellable_reset that behavior is
undefined if called from within cancelled handler.
* Add test for multiple concurrent operations using the same
cancellable.
https://bugzilla.gnome.org/show_bug.cgi?id=656387
Destroying a GDBusProxy in a thread used to race with NameOwnerChanged
being delivered to the main context's thread (GNOME #651133).
Also, g_dbus_proxy_call_sync in a thread would race with NameOwnerChanged
being delivered to the main context's thread and rewriting the name_owner
(GNOME #656039).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=656039
Bug-NB: NB#259760
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This changes the meaning of "properties_lock" from "lock for D-Bus
properties" to "lock for GObject properties".
The most common problem, and the only one I've reproduced in a regression
test, is name_owner, which can be updated by the thread that owns
the GDBusProxy's main context (i.e. the thread-default main context of
the thread that constructed it) at the same time that a blocking call
is made. When a GDBusProxy is constructed in a thread-pool thread for
short-term use, the main context will typically be the global default
main context (which is actively running in the main thread!), making
this extremely problematic.
The interface info is perhaps a theoretical concern - one thread could
conceivably set it at the same time that another thread uses it, but only
in relatively pathological situations. The current API for this does have
the problem that it returns a borrowed ref, but interface info is
hopefully permanent anyway.
The default timeout is probably only a theoretical concern - it's just an
int, so writes are indivisible, and there's no worry about whether
something has been freed - but to be safe, let's hold the lock for that
too.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=656039
Bug-NB: NB#259760
Signed-off-by: David Zeuthen <davidz@redhat.com>
This removes the need for async_init_get_name_owner_cb to cope with being
called without a real GAsyncResult, and will simplify the addition of
correct thread-locking.
In async_init_data_set_name_owner, use the name_owner parameter instead
of the corresponding member of GDBusProxyPrivate, partly to reduce
pointer-chasing but mainly to avoid needing to hold the lock.
Signed-off-by: David Zeuthen <davidz@redhat.com>
These ought to have thread-locking, and having it in the accessor seems
better than duplicating it here.
Signed-off-by: David Zeuthen <davidz@redhat.com>
If you run:
( cd gio/tests && G_DBUS_DEBUG=all ./gdbus-proxy-well-known-name )
you can see that in the case where the name com.example.TestService isn't
owned yet, the GDBusProxy calls GetAll() with no destination, resulting
in an error reply from the peer (the dbus-daemon itself). That's clearly
not right!
However, if priv->name is NULL, that indicates the special case where we
really do want to talk directly to a peer, instead of via the bus daemon
(most likely to be used on peer-to-peer connections); in that special
case, do call GetAll().
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is needed because the proxy may need to update its internal state
which a signal handler connected to the manager may rely on.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This avoids calling g_variant_unref and g_free on uninitialized memory
if PropertiesChanged is received in the creating thread's thread-default
main context's thread, at the same time as releasing the last ref in
another thread. This would result in "goto out" before the variables
freed after that label had been initialized to NULL.
Based on a patch by Simon McVittie, bug 656282
Prepare for the future where udisks will use $XDG_USER_DIR/Volumes
instead of /media when mounting filesystems on behalf of the user.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Found by GIR compiler when building gobject-introspection:
gir/gio-2.0.c:33525: Warning: Gio: g_tls_password_set_description: unknown
parameter 'flags' in documentation comment, should be one of 'password',
'description'
gir/gio-2.0.c:14568: Warning: Gio: g_action_group_action_state_changed: unknown
parameter 'state' in documentation comment, should be one of 'action_group',
'action_name', 'value'
The database is an abstract object implemented by the various TLS
backends, which is used by GTlsConnection to lookup certificates
and keys, as well as verify certificate chains.
Also add GTlsInteraction, which can be used to prompt the user
for a password or PIN (used with the database).
https://bugzilla.gnome.org/show_bug.cgi?id=636572
socket->priv->connected was only being set if g_socket_connect()
succeeded right away; in the case where it returns G_IO_ERROR_PENDING,
it never got set. Fix that by having g_socket_check_connect_result()
set it on success.
Otherwise, we may run into trouble as opening a peer-to-peer
connection uses a socket client, which uses a proxy resolver
which may end up using gsettings, whose dconf backend may end
up using the session bus to talk to dconfd...
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>
The code-generator already uses GVariant* so generated code didn't
really work at all. We want that instead of gint to avoid confusion
because a 'h' instance is an _index_ into a GUnixFDList, not a file
descriptor.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is possible now that we have better support for object path
arrays, see
http://git.gnome.org/browse/glib/commit/?id=19878998bc386db78614f1c92ff8524a81479c7b
Note that this breaks the ABI of generated code but since
gdbus-codegen(1) has never yet been in a stable GLib release, this is
fine.
Signed-off-by: David Zeuthen <davidz@redhat.com>
- move choice of statfs vs statvfs from gio/glocalfile.c to configure.ac
- if statvfs is the choice, then don't check number of arguments to statfs()
- use choice in gio/gunixmounts.c as well
https://bugzilla.gnome.org/show_bug.cgi?id=617949
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
-In gio/Makefile.am, the name for one of the filters for capturing the
sources for the GIO VS Project Files is corrected.
-Remove the GIO source file items in the VS project files templates as
a result for this change, and move the entry of the "new"
gregistrysettingsbackend.c into the filter in gio/Makefile.am
GAction is a read-only interface (as is visible by the lack of _set() functions
on its API). The properties on the interface currently force implementors to
support writing of the properties at construct time, however.
Lift that restriction.
Take advantage of this from GSimpleAction by nuking the set_property
function and setting the fields directly in the constructor.
This commit represents an API break to GAction in the following ways:
- the 'set_state' entry in the GActionInterface vtable has been
renamed to 'change_state'. The number and order of vtable items has
not otherwise changed.
- g_action_set_state() has been renamed to g_action_change_state() to
match the updated vtable entry.
- the "state" property of the GAction interface has been changed to
read-only to reflect the fact that g_action_set_state() no longer
exists.
- GSimpleActionClass has been hidden. GSimpleAction can no longer be
subclassed.
>> Rationale
g_action_set_state() has never been a true setter in the sense that
calling it will update the value of the "state" property. It has always
been closer to "request 'state' to be changed to this value" with
semantics defined by the implementor of the interface. This is why the
equivalent method in GActionGroup had its name changed from 'set' to
'change'. This change makes the two interfaces more consistent and
removes any implication about the effect that calling set_state() should
have on the 'state' property.
>> Impact
This incompatible API break was undertaken only because I strongly
suspect that it will go entirely unnoticed. If the break actually
affects anybody, then we will accommodate them (possibly going as far as
to revert this commit entirely).
The virtual table change only impacts implementors of GAction. I
strongly suspect that this is nobody (except for GSimpleAction).
The hiding of GSimpleActionClass only impacts impacts subclasses of
GSimpleAction. I strongly suspect that none of these exist.
The changing of the property to be read-only only affects people who
were trying to change the state by using GObject properties. I strongly
suspect that this is nobody at all.
The removal of the g_action_set_state() call is the most dangerous, but
I still suspect that it will impact nobody outside of GLib. If anybody
is impacted by this change then, at their request, I will reintroduce
the API as a deprecated alias for g_action_change_state().
