Allow for NULL GSourceFuncs.check() and .prepare().
For prepare() the source will be taken not to be ready and having an
infinite timeout. For check() the source will be taken not to be ready.
https://bugzilla.gnome.org/show_bug.cgi?id=686853
This avoids collecting the zombie child, which means that the PID
can't be reused. This prevents possible race conditions that might
occur were one to send e.g. SIGTERM to a child.
This race condition has always existed due to the way we called
waitpid() for the app, but the window was widened when we moved the
waitpid() calls into a separate thread.
If waitid() isn't available, we return NULL, and consumers of this
private API (namely, GSubprocess) will need to handle that.
https://bugzilla.gnome.org/show_bug.cgi?id=672102
0 is not a valid source id, but for long-lived programs that rapidly
create/destroy sources, it's possible for the source id to overflow.
We should handle this, because the documentation implies we will.
https://bugzilla.gnome.org/show_bug.cgi?id=687098
This is preparatory work for a future commit which will add a
"catchall" waitpid API. If we don't synchronize here with the worker
thread, race conditions are possible.
This also ensures we have an error message if someone adds a child
watch for a nonexistent pid, etc. Previously, we'd simply keep
calling waitpid() getting ECHILD, and ignoring it until the source was
removed. Now, we g_warning() and fire the source.
Thirdly, this ensures that the waitpid() call in gmain handles EINTR,
like the g_spawn_sync() one did.
https://bugzilla.gnome.org/show_bug.cgi?id=687061
Applications that use glib should not invoke waitpid with a first
argument that is nonpositive, because when such a waitpid is run in
one thread and glib waits for a subprocess in another, there is a race
condition, and the former waitpid can reap a process that was intended
for the latter. Mention this in the documentation for
g_child_watch_source_new, and in the diagnostic generated by
g_spawn_sync when its waitpid fails with errno equal to ECHILD.
Signed-off-by: Colin Walters <walters@verbum.org>
http://bugzilla.gnome.org/show_bug.cgi?id=687075
A parent source holds refs on its children, so if the child source is
destroyed, we need to drop that ref. Fix, and reorganize to make this
all more obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
If a context was freed with sources still attached, those sources
correctly got destroyed, but the corresponding GSourceList structs
were being leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=682560
g_source_get_context() was checking that the source wasn't destroyed
(since a source doesn't hold a ref on its context, and so
source->context might point to garbage in that case). However, it's
useful to be allowed to call g_source_get_context() on a source that
is destroyed-but-currently-running.
So instead, let g_source_get_context() return the context whenever
it's non-NULL, and clear the source->context of any sources that are
still in a context's sources list when the context is freed. Since
sources are only removed from the list when the source is freed (not
when it is destroyed), this means that now whenever a source has a
non-NULL context pointer, then that pointer is valid.
This also means that g_source_get_time() will now return-if-fail
rather than crashing if it is called on a source whose context has
been destroyed.
Add tests to glib/tests/mainloop to verify that g_source_get_context()
and g_source_get_time() work on destroyed sources.
https://bugzilla.gnome.org/show_bug.cgi?id=661767
Child sources are supposed to be blocked when their parents are, so
when adding a source to a blocked source, block the child too. Fixes a
warning when unblocking the parent.
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
