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
The source can be destroyed by the time we complete the result, and
then the g_source_get_context(current_source) call will cause
a critical error. We check for the source being destroyed and avoid
the check in that case.
This means we miss the right-thread check in this case, but thats
merely a helper, so this is not critical.
Metadata are really part of the pathname, not the target file
(as they are stored by pathname, and for many metadata like icon position
etc make not sense using the target data). So, even if nofollow
is not specified we should not follow links for metadata.
Ideally this should be implemented in the metadata extension in gvfs,
but the extension API does not allow this, so we do it in gio.
See https://bugzilla.gnome.org/show_bug.cgi?id=593809
Some recent versions of libtoolize output a version blurb like:
libtoolize (GNU libtool 1.3110 2009-07-01) 2.2.7a
Don't get confused by the numbers inside the parens.
