Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
Rather than having a single priority-ordered list of GSources, store a
list of queues of each priority level. This means that adding a source
is now O(n) in the number of unique priority levels currently being
used, rather than O(n) in the total number of sources.
https://bugzilla.gnome.org/show_bug.cgi?id=619329
A child source does not have a priority of its own; it must have the
same priority as its parent. Enforce this in
g_source_set_priority_unlocked().
https://bugzilla.gnome.org/show_bug.cgi?id=619329
When blocking a source that has child sources, we need to consider the
children blocked as well. Otherwise they will still trigger repeatedly
in an inner loop started from the parent source's callback.
https://bugzilla.gnome.org/show_bug.cgi?id=669260
And remove a comment about Windows in the fallback implementation that
no longer applies, since there's now a separate Windows-specific
implementation.
Adding a child source to an already-attached parent source would
crash, because we were passing the parent's context when setting the
child's priority.
01ed78d525cf2f8769022e27cc2573ec7ba123b3 introduced assertion checks for
creating a main context, forking, and attempting to use the main context
from the child side of the fork.
Some code (such as gnome-keyring-daemon) daemonise after calling
GMainContext. That's probably still mostly safe since we still only
have one side of the fork touching the context afterwards.
This use case is still troubling, however, since if any worker threads
have been created at the time of the fork(), we could end up in the
classic situation of leaving some mutexes in a locked state when the
other threads disappear from the copy of the image that the child gets.
This will require some deeper thinking...
Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.
The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).
If we mask all the signals in our worker, then this can't happen.
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().
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.
Change GThreadPool, GMainContext and GDBus to create named threads.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
This variable, which is the cause of much grief, exists for two reasons:
- ensuring the the wakeup pipe doesn't fill up
- preventing the first poll() after adding a source from waking up
immediately
The first point is no longer an issue with GWakeup.
The second point is addressed by using different logic: we only signal a
wakeup in the case that the context is currently acquired by a thread
that is not us.
As an added bonus, we can now implement g_main_context_wakeup() without
taking a lock.
https://bugzilla.gnome.org/show_bug.cgi?id=583511https://bugzilla.gnome.org/show_bug.cgi?id=320888
Since GMainLoop is now purely monotonic, it really doesn't make sense to
cache the wallclock time just for the sake of making a deprecated call
more efficient.
The first time this is called, this creates a GMainContext * and a
thread to run it. Future calls return the same. There are a lot of
places that we could use this in GLib.
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
Since there was nothing guaranteeing synchronization of the
assignments to checked and clockid, it would be possible for one
thread to set clockid = CLOCK_MONOTONIC, and for another thread to see
checked = TRUE but still clockid = CLOCK_REALTIME.
https://bugzilla.gnome.org/show_bug.cgi?id=655129
