This can be used for debugging, or for progress UIs ("Connecting to
example.com..."), or to do low-level tweaking on the connection at
various points in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=665805
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
Have one simple _get() API that returns the group immediately, in an
empty state. The group is initialised on the first attempt to interact
with it.
Leave a secret 'back door' for GApplication to do a blocking
initialisation.
GDBusConnection now dispatches GDestroyNotify calls back to the
mainloop. Adding an idle to the mainloop is O(n) in the number of idles
already there. We therefore need to periodically empty the mainloop to
avoid quadratic behaviour with a very large 'n'.
Exporting can only be done relative to a particular given main context
and all interaction with the action group must be on that same context.
Fix up the implementation so that the user can specify that context with
the normal (thread default) mechanism and document the limitation on the
API.
Adjust the testcase to adhere to the documentation limitations. It
passes now.
Sometimes randa and randb end up having the same state, causing them to
return the same stream of 'random numbers'. This is a problem for the
testcase that is looping to find unequal menus.
If we find ourselves in this state, throw one of the random generators
away and recreate it so we have a better chance of getting some unequal
menus.
Give it the same treatment as the exporter for GActionGroup just got.
There is a wart here: the exporter attempt to re-enter GDBusConnection
when it is freed in order to cancel outstanding name watches.
GDBusConnection holds its own lock while calling the destroy notify, so
the attempt at reentrancy results in a deadlock.
We have a workaround to deal with that for now...
Rename g_application_set_menu to g_application_set_app_menu and make a
couple of fixups. Clarify the documentation about exactly what this
menu is meant to be.
Add g_application_set_menubar and document that as well.
Create a 'mirror' model of the proxy for the testcase. In addition to
testing that the proxy model emits the proper signals this also keeps
the proxy alive (by holding references to it from the mirror).
The previous code would create the submenu proxies and destroy them
right away (from the recursive step in the equality comparison
functions). This means that the subscription would go out over D-Bus
and the proxy would be destroyed before it returned. Keeping the model
alive allows it to be actually updated.
Each test needs to remove the sources that it attaches
to the default main context, or else things will work
fine in isolation, but go bad in a full test run.
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
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.
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
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>
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
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.
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
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>
GDBusConnection sets the closed flag in the worker thread, then adds an
idle callback (which refs the Connection) to signal this in the main
thread. The tests session_bus_down doesn't spin the mainloop, so the
"closed" signal will always fire if iterating the mainloop later (and
drops the ref when doing so). But _is_closed can return TRUE even before
signalling this, in which case the "closed" signal isn't fired and the
ref isn't dropped, causing the test to fail.
Instead simply always wait for the closed signal, which is a good thing
to check anyway and ensures the ref is closed.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=661896
Reviewed-by: Matthias Clasen <mclasen@redhat.com>
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
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>
Since it is valid for a D-Bus interface / service to add new methods,
signals or properties we must NEVER warn about unknown properties or
drop unknown signals or disallow unknown method invocations when we
have an expected interface.
So this means that the expected_interface machinery is only useful for
checking that the service didn't break ABI.
Also update the docs so it is clear exactly what it means to have an
expected interface.
https://bugzilla.gnome.org/show_bug.cgi?id=660886
Signed-off-by: David Zeuthen <davidz@redhat.com>
These were the last users of the dynamic allocation API.
Keep the uses in glib/tests/mutex.c since this is actually meant to test
the API (which has to continue working, even if it is deprecated).
https://bugzilla.gnome.org/show_bug.cgi?id=660739
This reverts commit c841c2ce3f.
This approach has been an unmitigated disaster. We're getting all sorts
of crashes due to functions that are returning NULL because they can't
find the schema for the default value. The people who get these crashes
are then confused about the root cause of the problem and waste a lot of
time trying to figure it out.
Until we find a better solution, we should go back to what we had
before.
https://bugzilla.gnome.org/show_bug.cgi?id=655366
This tests the interaction between mimeinfo.cache, defaults.list and
mimeapps.list to ensure g_app_info_set_as_last_used_for_type doesn't
incorrectly change the default.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
The GApplication test case tried to fork() while using GMainLoop,
causing problems. Avoid doing that by splitting the child process into
a separate program and spawning it in the usual way.
https://bugzilla.gnome.org/show_bug.cgi?id=658999
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
The threaded tests are using the default main context in the worker
thread, but were not g_main_context_acquire()ing it first, which meant
that g_tls_interaction_invoke_ask_password() in the main thread would
sometimes succeed in acquiring it itself and thus performing the
operation in the wrong thread. Fix that.
Also, we can't unref the loop from the worker thread, because the main
thread isn't holding a reference on it, and so it might end up being
destroyed while that thread is still inside g_main_loop_quit().
(which shouldn't ever have been part of the API. Grr.)
Solaris /etc/services doesn't even have "http", which was causing
tests/network-address to fail...
* Add 'invoke' style method, which can be used to call an interaction
from any thread. The interaction will be run in the appropriate
#GMainContext
* Sync methods can be called whether main loop is running or not.
* Derived classes can choose to implement only sync or async
interaction method, and the invoke method will fill in the blanks.
* Documentation for the above.
* Tests for the above.
https://bugzilla.gnome.org/show_bug.cgi?id=657567
The test was using a socket in a temporary directory, but not actually
creating that temporary directory. This worked fine on Linux since it
actually ended up using an abstract socket instead, but failed on
unixes without abstract sockets.
https://bugzilla.gnome.org/show_bug.cgi?id=657517
The docs for g_socket_set_timeout() claimed that if an async operation
timed out, the GIOCondition passed to the source callback would be
G_IO_IN or G_IO_OUT (thus prompting the caller to call
g_socket_receive/send and get a G_IO_ERROR_TIMED_OUT), but in fact it
ended up being 0, and gio/tests/socket.c was erroneously testing for
that instead of the correct value. Fix this.
* 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
