There are no public 'exporter' objects, so don't allude to them
in the function names. At the same time, we want to make it clear
that these functions are D-Bus specific.
The new APIs are
g_action_group_dbus_export_start
g_action_group_dbus_export_query
g_action_group_dbus_export_stop
g_menu_model_dbus_export_start
g_menu_model_dbus_export_query
g_menu_model_dbus_export_stop
After questioning the semantics of flush on IRC, it seemed necessary to
clarify what flushing is supposed to do. The Linux man page for fflush()
seemed to cover it perfectly, so I just copied it.
I did not add the "via the underlying write mechanism" part as that in
my opinion is not something subclasses should need to guarantee.
This patch makes GFileMonitor to emit EVENT_CHANGES_DONE_HINT when
EVENT_CREATED is emitted but the file is not opened for writing.
On file moves across different mounted volumes, inotify will always emit
IN_CREATE and IN_CLOSE_WRITE (plus other events).
This translates into GIO's _EVENT_CREATED and _EVENT_CHANGES_DONE_HINT.
On file moves across the same mounted volumes, inotify will emit
IN_MOVED_FROM/IN_MOVED_TO which will be translated into
_EVENT_DELETED/_EVENT_CREATED GIO's side. No _EVENT_CHANGES_DONE_HINT is
emited afterwards.
Under such circumstances a file indexer does not know when actually the
file is ready to be indexed, either waiting too much or triggering the
indexing twice. On small devices it's not advisable.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=640077
Bug-NB: NB#219982
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Tomas Bzatek <tbzatek@redhat.com>
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>
This is useful in peer-to-peer connections.
With minor changes by David Zeuthen <davidz@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=662718
Signed-off-by: David Zeuthen <davidz@redhat.com>
A g_input_stream_read_async() implementation can't call
g_input_stream_read() on itself directly because it will fail because
the pending flag is already set. So fix that by invoking the vmethod
directly rather than calling the wrapper. Likewise with
GMemoryOutputStream.
Add a test to gio/tests/memory-input-stream.c to catch read_async
failures in the future.
g_file_set_attribute() also permits a NULL value for value_p, and requires it
to be NULL to unset it. Also fix the wrong variable name in the documentation.
Signed-off-by: Martin Pitt <martin.pitt@ubuntu.com>
This new API allows requesting multiple pieces of information about a
particular action in one go and also simplifies the burden for
GActionGroup implementations -- they need not implement all the separate
APIs now.
This is the ISO C sense of undefined behaviour, in which
works-by-coincidence, critical warning, abort, demons-fly-out-of-your-nose
are all valid implementations.
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>
This was a regression in commit f41178c6c: flush_async_data wasn't
necessarily NULL in the "don't flush" case.
Also move initialization of these variables up so that it's
unconditional, since that's easier to verify than checking
that each branch gets it right.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664617
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we can't get on the session bus, just behave like a normal non-unique
application.
This turns out to be remarkably easy to implement and lets us avoid
adding a 'dummy' backend.
Add a test for this case as well.
Idea from Zachary Dovel.
https://bugzilla.gnome.org/show_bug.cgi?id=651997
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>
These might even make useful public API if they grew a Windows
implementation, but for now they can be Unix-only test API.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
We didn't previously flush in a couple of cases where we should have
done:
* a write is running when flush is called: we should flush after it
finishes
* writes have been made since the last flush, but none are pending or
running right now: we should flush the underlying transport straight
away
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
This makes it easier to schedule a flush, by putting it on the same code
path as writing and closing.
Also change message_written to expect the lock to be held, since all
that's left in that function either wants to hold the lock or doesn't
care, and it's silly to release the lock immediately before calling
message_written, which just takes it again.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
When we use this function to schedule a flush, it'll be called
with the lock held. Releasing and immediately re-taking the lock would
be pointless.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
maybe_write_next_message now also closes, and I'm about to make it
consider whether to flush as well, so its name is increasingly
inappropriate. Similarly, write_message_in_idle_cb is a wrapper around
it which could do any of those things.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
If the user calls flush_sync() with no messages in the queue, but an
async write call pending, then we ought to flush after that async write
returns (although we don't currently do that). If it was an async close
or flush that was pending, there's no need to flush (again) afterwards.
So, we need to distinguish.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
PKCS#8 is the "right" way to encode private keys. Although the APIs do
not currently support encrypted keys, we should at least support
unencrypted PKCS#8 keys.
https://bugzilla.gnome.org/show_bug.cgi?id=664321
The connect_async() calls would never terminated when an application side
proxy was being used. Note we also skip over TLS handshake in this case,
as the application may have to do some proxy handshake before.
The proxy address was not cleared between each attempt. That would lead
to leak or worse, trying to do the proxy handshake on the final
destination address. To make all this safer, I have regroup all the cleanup
where the iterations starts.
https://bugzilla.gnome.org/show_bug.cgi?id=664141
Any method that has its prefix'd argument as its first parameter will be
interpreted by introspection as a method. We don't want this, so we need
to swap the first two parameters.
This is strictly redundant now that we can get the ID from the schema
itself. Its only other purpose was to get the schema name from the
set_property() call to the constructed() call and we can avoid that by
doing the schema lookup at the time of the property being set.
Instead of building a reversed linked list by prepending in order and
then reversing it at the end, prepend in reverse by iterating backwards
through the directories (to get a list in-order when we're done).
These functions no longer have anything to do with GSettings itself, so
they should not be in that file anymore.
GSettings still wants direct access to the GSettingsSchemaKey structure,
so put that one in gsettingsschema-internal.h.
We now avoid the per-enumerated-file stat for type and names. We could
improve this further by moving things to the no_stat function, but this
is what the file chooser needs for autocomplete, so I am happy.
We now sort the matchers and remove unnecessary duplicates (like
removing standard:type when we already match standard:*), so that we can
do more complex operations on them easily in later commits.
Include the hostname (or proxy hostname if it was the connection to
the proxy server that failed) in the GError message when
g_socket_client_connect* fail.
https://bugzilla.gnome.org/show_bug.cgi?id=661266
Previously, if you created a GUnixInputStream or GUnixOutputStream
from a non-blocking file descriptor, it might sometimes return
G_IO_ERROR_WOULD_BLOCK from g_input_stream_read/g_output_stream_write,
which is wrong. Fix that. (Use the GPollableInput/OutputStream methods
if you want non-blocking I/O.)
Also, add a test for this to gio/tests/unix-streams.
Also, fix the GError messages to say "Error reading from file
descriptor", etc instead of "Error reading from unix" (which was
presumably from a bad search and replace job).
https://bugzilla.gnome.org/show_bug.cgi?id=626866
Add GNetworkMonitor and its associated extension point, provide a base
implementation that always claims the network is available, and a
netlink-based implementation built on top of that that actually tracks
the network state.
https://bugzilla.gnome.org/show_bug.cgi?id=620932
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>
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
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>
As part of the deserialisation process of a zero-length array in the
DBus wire format, parse_value_from_blob() recursively calls itself with
the expectation of failing (as can be seen by the assert immediately
following).
It passes &local_error to this always-failing call and then fails to
free it (indeed, to use it at all). The result is that the GError is
leaked.
Fix it by passing in NULL instead, so that the GError is never created
in the first place.
https://bugzilla.gnome.org/show_bug.cgi?id=662411
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>
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>
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>
We didn't previously test anything except the implicit default of TRUE.
Now we test implicit TRUE, explicit TRUE, explicit FALSE, and
disconnecting at the local end (which regressed while fixing Bug #651268).
Also avoid some questionable use of a main context, which fell foul of
Bug #658999 and caused this test to be disabled in master.
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: David Zeuthen <davidz@redhat.com>
This was a regression caused by my previous work on GDBusWorker thread-safety
(Bug #651268). The symptom is that if you disconnect a GDBusConnection
locally, the default implementation of GDBusConnection::closed
terminates your process, even though it shouldn't do that for
locally-closed connections; this is because GDBusWorker didn't think a
cancelled read was a local close.
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: David Zeuthen <davidz@redhat.com>
