The function does not initialise the struct tm,
giving it improper values of tm_isdst making the result
an hour out.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=603540
(cherry picked from commit 2321e5aed07154761223bb124770beba56700e41)
Not only is the default implementation broken (it causes infinite recursion
as seen in bug #603982), but its also worthless. If we just fall back on the
default stream operations we automatically get async version based on
the sync filter stream operations, which is what we want.
(cherry picked from commit 4fbbe190b7cbfd271bbb18428bc103ebffa41112)
Improve handling of g_file_query_default_handler() when called on an
invalid GFile (ie: one created with an invalid URI).
(cherry picked from commit 9681d7e75f2d1296a890bfa64b3478ea7025df62)
We used to pass the path for the symlink, but the device of the target
which is wrong and breaks metadata access.
https://bugzilla.gnome.org/show_bug.cgi?id=593809
(cherry picked from commit 2b2195bf68bf68837dc9f6b4765d3716694f42b3)
If g_io_win32_sock_close() has been called on a socket channel, don't
later in g_io_win32_free() call WSAEventSelect() on its fd which has
been set to -1.
The patch ensures that multibyte character sets are properly
nul-terminated. This is an issue because the documentation claims to
return a "nul-terminated" string and users of the API assume that means
a proper nul-termination in the resulting character set.
I looked at Pidgin and GStreamer code and found at least 3 cases where
this was happening.
This patch also reverts the documentation change from
8c936178a130f06511164dbd317180177da6b448 as that is now no longer
necessary.
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
GWin32DirectoryMonitor was quite broken, but nobody had apparently
noticed, or at least not filed any bug. Only now with a bleeding edge
GTK+ file chooser does the code get exercised in common programs like
gtk-demo or GIMP, apparently. Bug #598899.
Store whether the object has a toggleref before decrementing the
refcount to prevent race condition when two threads simultaneously
try to unref an object with a refcount of 2.
Patch by Antoine Tremblay.
https://bugzilla.gnome.org/show_bug.cgi?id=551706
This avoids a bunch of code and makes construction of simple objects
faster.
Object construction performance improvement:
Non-Threaded Threaded
Simple: 14% 5%
Complex: -1.1% -2.2%
Other tests stable.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
If the class has no properties there could be no notification anyway.
This is an important optimization for construction of simple objects.
Object construction performance improvement:
Non-Threaded Threaded
Simple: 84% 91%
Complex: -1.4% -0.6%
Other tests stable.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
This is both cleaner and faster (it avoids function calls and
zeroing the memory twice).
Object construction performance improvement:
Non-Threaded Threaded
Simple: 11% 1.3%
Complex: 8% 6%
Other tests stable.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
These are basic performance test for a couple of basic gobject
primitives:
* construction of simple objects. Simple is a bare gobject derived
class with no properties, signals or interfaces.
* construction of complex objects. Complex is a gobject subclass
with construct properties, normal properties, signals, and
implements an interface.
* run-time type check of complex objects
* signal emissions
Lots of care is taken to try to make the results reproducible. Each
test is run for multible "rounds", where we try to make each round be
"not too short" in order to be significant wrt timer accuracy, but
also "not to long" to make the probability of some other random event
happening on the system (interrupts, other process scheduled, etc)
during the round less likely.
The current target round time is 4 msecs, which was picked without
rigour, but seems small wrt e.g. scheduler time.
For each test we then run the calculated round size for 60 seconds,
and then report the performance based on the minimal time of one
round. The model here is that any random stuff that happens during a
round can only slow it down, there is nothing that can make it go
faster, so the minimal time is the best estimate of how fast one round
goes.
The result is not ideal, even on a "idle" system the results vary
from round to round, but the variation seems to be less than 1%.
So, any performance difference reported by this test over 1% is
probably statistically significant.
Additionally the tests can be run with or without threads being
initialized. The script tests/gobject/run-performance.sh makes
it easy to produce a performance report for the current checkout.
https://bugzilla.gnome.org/show_bug.cgi?id=557100
