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
