If a given fd is being polled by multiple sources, we used to pass it
multiple times to g_poll(), which is technically illegal (and not
supported by the select()-based fallback implementation of poll() in
gpoll.c), and also made it more likely that we'd exceed the maximum
number of pollfds.
Fix it to merge together "duplicate" GPollFDs. The easiest way to do
this involves re-sorting context->poll_records into fd order rather
than priority order. This means we now have to walk the entire pollrec
list for every g_main_context_query() and g_main_context_poll(),
rather than only walking the list up to the current max_priority.
However, this will only have a noticeable effect if you have tons of
GPollFDs, and we're already too slow in that case anyway because of
other O(n) operations that happen too often. So this shouldn't change
much (and the new poll API will eventually let us be cleverer).
Remove some win32-specific code which did the same thing (but was
O(n^2)).
https://bugzilla.gnome.org/show_bug.cgi?id=11059
We called getopt() to try to find out of the platform on which we are
running defaults to strict POSIX-style argument handling (ie: flags
following the first filename are considered as further filenames rather
than flags).
This is the default case on BSDs, for example. It is also the case on
GNU systems with the POSIXLY_CORRECT environment variable set.
Unfortunately many of our tools rely on being able to accept commandline
arguments in the non-strict ordering and the code for making these calls
is spread widely (for example in Makefile fragments invoking some of our
build tools).
For this reason we need to revert the getopt() check and only enable
strict POSIX mode in the case that the application explicitly opts into
it using the _set_strict_posix() API.
This also fixs a failure to build on Windows due to missing getopt().
https://bugzilla.gnome.org/show_bug.cgi?id=723160
With this patch it is fine to call g_hash_table_lookup and
g_hash_table_remove from destroy notification functions. Before
this could lead to an infinitie loop if g_hash_table_remove_all
was used.
https://bugzilla.gnome.org/show_bug.cgi?id=695082
Add a "posixly correct" mode to GOption to stop parsing arguments as
soon as the first non-option argument is encountered.
We determine the default value on the basis of duplicating the behaviour
of the system getopt() implementation (which we directly check the
behaviour of at runtime). On GNU systems this allows the user to modify
our behaviour using POSIXLY_CORRECT.
The user can change the value by g_option_context_set_strict_posix(),
which might be useful for some usecases of GOptionContext (as mentioned
in the doc string of this new function).
https://bugzilla.gnome.org/show_bug.cgi?id=723160
g_get_monotonic_time() and g_get_real_time() now always use different
clocks, so we cannot avoid correcting for their offset. Fixes failure
to time out on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=738197
Internal allocation size (array->alloc) was being kept to 0 when a new
GByteArray was created from an already existing heap-allocated buffer.
Among other things, this was making g_byte_array_set_size() fully clear all
the buffer contents (not just the newly allocated memory) when
G_DEBUG=gc-friendly was being used...
if (G_UNLIKELY (g_mem_gc_friendly))
memset (array->data + array->alloc, 0, want_alloc - array->alloc);
https://bugzilla.gnome.org/show_bug.cgi?id=738170
If a GSource is created, *not* attached to a GMainContext, and then has
child sources added, dropping the last reference to the parent GSource
will leak its references to its child sources. Currently, child sources
are only unreffed when g_source_destroy() is called on the parent.
https://bugzilla.gnome.org/show_bug.cgi?id=737338
This ensures the uintptr_t type is defined on mingw-w64.
Fixes compile error:
make[4]: Entering directory
`/home/abuild/rpmbuild/BUILD/glib-2.42.0/gobject'
CC libgobject_2_0_la-gtype.lo
In file included from gtype.c:24:0:
../glib/valgrind.h: In function 'VALGRIND_PRINTF':
../glib/valgrind.h:5601:4: error: unknown type name 'uintptr_t'
uintptr_t _qzz_res;
^
https://bugzilla.gnome.org/show_bug.cgi?id=737143
Step up thread safety on g_source_set_name() to the same standard as all
other GSource functions: after we are attached to a main context, this
function should be threadsafe.
https://bugzilla.gnome.org/show_bug.cgi?id=736683
Document that one must not use the "by id" source APIs with non-existent
IDs. The real justification behind this restriction is that the reuse
of source ids makes it unsafe to call these functions unless you're
absolutely sure that the source exists and it belongs to you. If you
call one of these functions on a source that may already have been
removed then you run the risk of finding someone else's source (with
your reused id).
This also bails us out of a slightly tricky situation with respect to
the threadsafety of g_main_context_find_source_by_id(). The fact that
this function doesn't return a reference implies that its return value
cannot be safely accessed unless we already know for sure that a
reference is being held elsewhere (by example, by the main context
itself if we know that the source has not been removed). The function
itself, however, performs an access to the value, which could result in
a crash.
If we mandate that it is only valid to call this function on
known-to-exist source IDs then we dodge this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=736683
This confused me for a while, because it isn't the same as D-Bus.
Like GVariant, the D-Bus serialization needs an out-of-band
endianness and type indicator, but unlike GVariant, serialized
D-Bus objects encapsulate their own length (often by starting with
a byte-count). This does come at some redundancy cost, so I can see
why the more efficient GVariant format does this the way it does;
but it's a difference between D-Bus and GVariant that seems worth
calling out.
It's also relevant for the designers of file or message-framing
formats: with D-Bus serialization it would be feasible to say "the file
starts with a little-endian D-Bus variant, followed by...",
but in GVariant you wouldn't be able to deserialize the variant
unless you either assume that it extends to end-of-file, or have
an explicit length.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=736975
Reviewed-by: Ryan Lortie
For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
As an example, the core of gedit is in a private library
placed in %INSTALLDIR%/lib/gedit/libgedit.dll
Before this patch we would get %INSTALLDIR%/lib/gedit as the
installation package dir, while what we actually want is to get
%INSTALLDIR%
https://bugzilla.gnome.org/show_bug.cgi?id=733934
Practically no caller of these functions require atomic behaviour,
but the atomics are much slower than normal operations, which makes
it desirable to get rid of them. We have not done this before because
that would be a break of the ABI.
However, I recently looked into this and it seems that even if the
atomics *are* used for g_clear_* it is not ever safe to use this. The
atomics protects two threads that are racing to free a global/shared
object from freeing the object twice. However, any *user* of the global
object have no protection from the object being freed while in use,
because there is no paired operation the reads and refs the object
as an atomic unit (nor can such an operation be implemented using
purely atomic ops).
So, since nothing could safely have used the atomic aspects of these
functions I consider it acceptable to just remove it.
https://bugzilla.gnome.org/show_bug.cgi?id=733969
This reverts commit 7269d75321b9d2a967a59fb35f243397f577eb41.
Adding G_STATIC_ASSERT() into a header file caused compilation
problems with at least one app (Anjuta). Reverting to keep
GNOME continuous testing running.
https://bugzilla.gnome.org/show_bug.cgi?id=730932
This code assumes that int is exactly 4 bytes, and that pointers
are either 4 or 8 bytes, on platforms with __ATOMIC_SEQ_CST.
In practice this is going to be true.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=730932
Since we are getting passed Unicode values these global vars
might not have the correct value. Instead always get the wide arguments
and convert them to utf8 to use them.
https://bugzilla.gnome.org/show_bug.cgi?id=733146
Detect the following two errors:
- attempting to unlock a mutex that is not locked
- attempting to clear a mutex that was not initialised or was
initialised but is still locked
Both of these are fatal errors. We avoid using g_error() here because
doing so would involve calls back into the GMutex code, and if things
are going off the rails then we want to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
If we have futex(2) then we can implement GMutex natively and gain a
substantial performance increase (vs. using pthreads).
This also avoids the need to allocate an extra structure in memory when
using GMutex or GCond: we can use the structure directly.
The main reason for the increase in performance is that our
implementation can be made more simple: we don't need to support the
array of options on pthread_mutex_t (which includes the possibility, for
example, of being recursive).
The result is a ~30% improvement in uncontended cases and a much larger
increase (3 to 4 times) in contended cases for a simple testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=731986
When GLib had been told to expect message X, but then actually saw
message Y, it would log the "did not see expected message" error with
message Y's log level and domain, which makes no sense. Change it to
log with domain "GLib" and G_LOG_LEVEL_CRITICAL instead.
Also, include the expected domain in the error message, so that if
that's the reason why the expectation didn't match, you can tell that
from the error message.
Update glib/tests/testing.c for these changes; for all other test
programs in GLib and elsewhere, this change should not break any
existing tests, it should only improve the output on failure.
https://bugzilla.gnome.org/show_bug.cgi?id=727974
...so that builds of GLib on x64 Visual C++ can be restored, as the build
fails in line 449 of valgrind.h as it only supports MinGW/GCC for x64
Windows and simply will not build otherwise. Make the x64 Visual C++
builds compile again by defining NVALGRIND when GLib is being built for
Windows on x64 Visual C++.
https://bugzilla.gnome.org/show_bug.cgi?id=732465
- g_subprocess_launcher_spawn() and spawnv(): there is no other way
AFAIK to create a GSubprocess from a launcher. So these
functions are not "convenience helper".
- annotate optional arguments for g_shell_parse_argv().
- other trivial fix
https://bugzilla.gnome.org/show_bug.cgi?id=732357
