This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GDesktopAppInfo violates the GObject rule that your C constructors
should just be thin wrappers around g_object_new(). While GKeyFile
isn't introspctable, this patch allows from JavaScript:
var app = new Gio.DesktopAppInfo({ filename: '/path/to/foo.desktop' });
https://bugzilla.gnome.org/show_bug.cgi?id=648425
When an old pre-thread-default-context API that takes an explicit
GMainContext wants to call a gio API, it must call
g_main_context_push_thread_default() before, and
g_main_context_pop_thread_default() after the gio call, so that the
gio method will return its result to the desired GMainContext.
But this fails for methods like g_socket_client_connect_async() that
make a chain of multiple async calls, since the pushed/popped context
will only affect the initial call.
Fix this by having GSimpleAsyncResult itself push/pop the context
around the callback invocation, so that if the callback queues another
async request, it will stay in the same context as the original one.
https://bugzilla.gnome.org/show_bug.cgi?id=646957
-Added projects to compile the glib-compile-schemas and gsettings utilities
-Update .vsprops to install these in "install" phase
-Distribute these projects also
-Added projects to compile the glib-compile-schemas and gsettings utilities
-Update .vsprops to install these in "install" phase
-Distribute these projects also
Older versions of libdbus would let you construct an invalid
DBusMessage, but that's a bug, which will be fixed in 1.4.8/1.5.0.
Instead, construct a valid message of the same length, then replace
substrings in the serialized blob with their invalid counterparts.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=646326
Signed-off-by: David Zeuthen <davidz@redhat.com>
... this was causing a GDBus test-case to fail so now that it is
fixed, also reenable the test case.
https://bugzilla.gnome.org/show_bug.cgi?id=631379
Signed-off-by: David Zeuthen <davidz@redhat.com>
In the previous code, if the timezone was pulled out of the cache again
just as the last reference was being dropped, the cache code will
increase its refcount and return it while the unref code was freeing it.
Protect against that.
Closes#646435.
If g_bus_get_sync() fails in authentication (because e.g. the process
uid, doesn't match the expected in EXTERNAL), a secondary call to
g_bus_get_sync() would notice we aren't initialized, and try
to initialize.
The assertion here is just wrong; we now explicitly and clearly handle
both cases where we already have an error, or we already succeeded.
https://bugzilla.gnome.org/show_bug.cgi?id=635694
