-Reinstate build/win32/vs10/glib.sln with the correct EOL (DOS/Windows) so
that the file can be correctly recognized by Windows, rather than having
the "Unrecognized Visual Studio Version".
-Update the main GLib projects to output the DLL/LIB file into <Release or
Debug>\<Win32 or x64>\bin for all configurations.
-Update/simplify the property sheets to copy all DLL and LIB files from
<Release or Debug>\<Win32 or x64>\bin for all configurations.
-Update the VS 2008 property sheet to seperate the intermediate directories
for all projects as well to avoid errors/warnings of being unable to
write/access the PDB files as they are in use.
The Linux eventfd() call is basically tailor made for the main loop
wake up pipe - all we want is a threadsafe way to write to a file
descriptor, and wake up the context on the other end; we don't care
about the content at all.
The eventfd manual page basically explains the benefits:
Applications can use an eventfd file descriptor instead of a
pipe (see pipe(2)) in all cases where a pipe is used simply to
signal events. The kernel overhead of an eventfd file
descriptor is much lower than that of a pipe, and only one file
descriptor is required (versus the two required for a pipe).
When writing my multithreaded spawn test case I actually hit the 1024
file descriptor limit quickly, because we used 2 fds per main context.
This brings that down to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=653140
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
... otherwise we might end up using the worker after it has been
freed. Reported by Dan Winship and Colin Walters.
This fix uncovered a bug in the /gdbus/nonce-tcp test case so "fix"
that as well to use a better way of having one thread wait for another
(using quotes for the word "fix" since it's pretty hackish to
busy-wait in one thread to wait for another).
Signed-off-by: David Zeuthen <davidz@redhat.com>
-Seperate intermediate directories for each project to avoid intermittent
MSBuild errors that a build log cannot be written while in use, and
update the property sheet as necessary.
-Minor cleanups of uneeded tags in the projects/properties
These tools require the use of GModule headers also, so update the include
directories so that the correct gmodule.h will be included instead of the
system-installed version.
These will validate the resulting line, and throw a conversion error.
In practice these will likely be used by bindings, but it's good
for even C apps too that don't want to explode if that text file
they're reading into Pango actually has invalid UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
g_data_input_stream_read_line() and
g_data_input_stream_read_line_finish() don't do any encoding checks,
so we shouldn't call the returned value a "string" (which I'd like to
mean UTF-8). Annotate them as byte arrays and add encoding warnings
to the docstrings.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
There is no chance that an unsigned integer value will be negative after
we do the bounds check that enforces its non-negativity.
Caught by Matthias running Coverity.
Running gthread/tests/spawn-multithreaded in a loop, I very easily hit:
GLib-CRITICAL **: g_main_context_wakeup: assertion `g_atomic_int_get (&context->ref_count) > 0' failed
Testing the refcount still left a window where we would fall into the
assertion. Fix this by just locking the context.
