For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.
Fix that up.
Also: fix some overzealous asserting in the testcases. Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.
This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.
Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=743636
There was a theoretical deadlock between the worker trying to emit a
signal at the same time as we were waiting for it to shutdown the
notification (while holding the lock).
The deadlock was particularly annoying because we didn't really need to
wait for the shutdown and because it wasn't possible to signals to
arrive while waiting for a start. Attempting to deal with start and
stop in an asymmetric way could have lead to other weird situations,
however.
Drop the lock while waiting for the worker thread to start. This means
that we face the possibility of multiple waiters on the cond at the same
time, so we need to make more of a state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
We install win32-software/autorun.exe (as test data for mime scanning)
only on UNIX builds, so don't attempt to chmod it on 'make install'
unless we're on UNIX.
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
This is *significantly* more pleasant to use from C (while handling
errors and memory cleanup).
While we're here, change some ugly, leaky code in
tests/desktop-app-info.c to use it, in addition to a test case
in tests/file.c.
https://bugzilla.gnome.org/show_bug.cgi?id=661554
delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).
This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure. It should still be fixed, however.
https://bugzilla.gnome.org/show_bug.cgi?id=743990
Make sure that we only match the _get_type() function name by
restricting the regexp to matching [A-Za-z0-9_]. We were matching on .*
before which means that if we had two _get_type() functions appearing on
a single line then we would get everything in between them included (by
the default rule of '*' being greedy).
This affected G_DECLARE_*_TYPE which puts several uses of _get_type()
into a single line.
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
Add a unit test that checks g_socket_new_from_fd by creating
a gsocket, obtaining its fd, duplicating the fd and then creating
a gsocket from the new fd. This shows a hang on win32 since the
gsocket created from the fd never receives the FD_WRITE event
because we wait for the condition without first trying to write
and windows signals the condition only after a EWOULDBLOCK error.
https://bugzilla.gnome.org/show_bug.cgi?id=741707
Fix two problems:
1) If g_socket_service_stop is called before the accept call is requeued,
then the reference count won't decrease and this code will hang forever:
while (G_OBJECT (service)->ref_count == ref_count)
g_main_context_iteration (NULL, TRUE);
2) Sometimes the testcase fails (maybe 1 in 200 times for me):
GLib-GIO:ERROR:socket-listener.c:73:connection_cb: assertion failed
(G_OBJECT (service)->ref_count == 2): (3 == 2)
Aborted (core dumped)
The problem is that depending on ordering, cancellation of the async
listener can require further main context iterations before it releases
the reference on the socket service. Furthermore, in some cases, it
requires at least one iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=712570
Add a property to GNetworkMonitor indicating the level of network
connectivity: none/local, limited, stuck behind a portal, or full.
The default implementation just returns none or full depending on the
value of is-available.
https://bugzilla.gnome.org/show_bug.cgi?id=664562
Add G_IO_ERROR_CONNECTION_CLOSED as an alias for
G_IO_ERROR_BROKEN_PIPE, and also return it on ECONNRESET.
It doesn't really make sense to try to distinguish EPIPE and
ECONNRESET at the GLib level, since the exact choice of which error
gets returned in what conditions depends on the OS. Given that, we
ought to map the two errors to the same value, and since we're already
mapping EPIPE to G_IO_ERROR_BROKEN_PIPE, we need to map ECONNRESET to
that too. But the existing name doesn't really make sense for sockets,
so we add a new name.
https://bugzilla.gnome.org/show_bug.cgi?id=728928
This is a convenience method for creating a GNetworkAddress which is
guaranteed to return IPv4 and IPv6 loopback addresses. The program
cannot guarantee that 'localhost' will resolve to both types of
address, so programs which wish to connect to a local service over
either IPv4 or IPv6 must currently manually create an IPv4 and another
IPv6 socket, and detect which of the two are working. This new API
allows the existing GSocketConnectable machinery to be used to
automate that.
Based on a patch from Philip Withnall.
https://bugzilla.gnome.org/show_bug.cgi?id=732317
Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).
This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().
Fix by moving the check for main_options up.
https://bugzilla.gnome.org/show_bug.cgi?id=740157
da053e34 broke the tls-certificates test by requiring the backend to
implement g_tls_certificate_verify() (which the test TLS backend
didn't). Add a trivial implementation to make the test pass again;
we'll need something more complicated when we add tests that are
supposed to get errors.
GResolver doesn't do full validation of its inputs, so in some of
these tests, the fact that we were getting back
G_RESOLVER_ERROR_NOT_FOUND is because the junk string was getting
passed to an upstream DNS resolver, which returned NXDOMAIN. But if
there's no network on the machine then we'd get
G_RESOLVER_ERROR_INTERNAL instead in that case.
Redo the code for type-based selection of applications (all,
recommended, default, fallback) based on the new DesktopFileDir
structures that we introduced last cycle.
At the same time, we expand the functionality to add support for the new
features of the specification:
- moving ~/.local/share/applications/mimeapps.list to ~/.config/
- per-desktop default applications (via XDG_CURRENT_DESKTOP)
- sysadmin customisation of defaults (via /etc/xdg/mimeapps.list)
- deprecation of the old defaults.list, favouring the use of
/usr/share/applications/mimeapps.list (or gnome-mimeapps.list) to
accomplish the same
We modify the mimeapps testcase to check for mimeapps.list having been
created in XDG_CONFIG_HOME instead of XDG_DATA_HOME.
The modification is a net reduction of code (due to less duplication in
bookkeeping). It is also an increase in performance and reduction in
memory consumption (due to simplified data structures). Finally, it
removes the stat-based timestamp checking in favour of the
GFileMonitor-based approach that was already being used in the
implementation of DesktopFileDir (in order to know if we had to rescan
the desktop files themselves).
https://bugzilla.gnome.org/show_bug.cgi?id=728040
We currently assume that setting an application as the default will take
it to the front of the list of supported applications for a given type,
but this is not necessarily true.
Check instead that the application is actually set as default.
https://bugzilla.gnome.org/show_bug.cgi?id=728040
