gtask: remove hardcoded GTask thread-pool size

GTask used a 10-thread thread pool for g_task_run_in_thread() /
g_task_run_in_thread_sync(), but this ran into problems when task
threads blocked waiting for another g_task_run_in_thread_sync()
operation to complete. Previously there was a workaround for this, by
bumping up the thread limit when that case was detected, but deadlocks
could still happen if there were non-GTask threads involved. (Eg, task
A sends a message to thread X and waits for a response, but thread X
needs to complete task B in a thread before returning the response to
task A.)

So, allow GTask's thread pool to be expanded dynamically, by watching
it from the glib worker thread, and growing it (at an
exponentially-decreasing rate) if too much time passes without any
tasks completing. This should solve the deadlocking problems without
causing sudden breakage in apps that assume they can queue huge
numbers of tasks at once without consequences.

https://bugzilla.gnome.org/show_bug.cgi?id=687223

glib-compile-schema: Don't accept duplicate docs

This schema compiler was completely ignoring <summary> and
<description> tags. Unfortunately, there are modules out there
who merge translations for these back in, with xml:lang. And
this is giving dconf-editor a hard time. Since this is not
how translations of schemas are meant to be done, just
reject such schema files.

Also add tests exercising the new error handling.

https://bugzilla.gnome.org/show_bug.cgi?id=747209

Updated Russian translation

Make glib-compile-resources a little smarter

glib-compile-resources was guessing a filename ending
in .c when generating sources, but did not do the same
for headers. Fix it so it generates a .h file when
guessing the filename for headers.

https://bugzilla.gnome.org/show_bug.cgi?id=746753

Clarify a confusing string

Relative was repeated twice here, when clearly what was meant is
relative or absolute. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=726447

inotify: fix move event matching accounting

The hash table stores the list of unmatched IN_MOVE_FROM events, but we
were removing entries from it when popping IN_MOVE_TO events.

Fix that up to correct a crash in nautilus due to the assertion failure
below.

https://bugzilla.gnome.org/show_bug.cgi?id=746749

file monitors: fix a typo

Due to a typo, a rename reported via a pair of delete/create events (due
to the watcher not giving the flag for moves to be paired) was
accidentally reported as being created with the old name instead of the
new name.

Fix that.

GListModel: roll back use of type redefinition

We declare the typedefs for GListModel and GListStore in giotypes.h, as
a matter of convention.  This is not actually required, since the
typedef is emitted as part of the G_DECLARE_* macros.

The giotypes.h approach is only used to avoid cyclic dependencies
between headers, which is not a problem in this case.

Type redefinition is a C11 feature, and although it was around in some
compilers before then, gcc 4.2.1 (from 2007) is apparently still in wide
use, being the default compiler for OpenBSD.

Eventually, we will probably hit a case where we actually need to
redefine a type, but since we're not there yet, let's back off a bit.

Update Czech translation

GClosure: add valgrind hints

GClosure has been in the "allocate area before the pointer" game since
before we did this with GTypeInstance.  At the time that this was done
for GClosure, we didn't have valgrind.h in GLib.

Now that we do, we should add similar valgrind hints as the ones we did
for GTypeInstance.  This substantially reduces reports of "possibly
lost" on pretty much any program that makes use of signals.

https://bugzilla.gnome.org/show_bug.cgi?id=739850

Fix the build

The world would be a better place if gcc had __has_feature(), too.

Account for clangs lack of __alloc_size__

clang's emulation of gcc 4.3 is not perfect, despite its
pretending that it is.

https://bugzilla.gnome.org/show_bug.cgi?id=745821

Updated Turkish translation

gsocket: Document FD ownership with g_socket_new_from_fd()

https://bugzilla.gnome.org/show_bug.cgi?id=730188

Updated Danish translation

Updated German translation

Updated Basque language

gversionmacros: add 2.46 version macros

gmain: Save errno when handling unix signals

Our signal handler calls write() on a pipe or an eventfd in order to
deliver the notification.  It's unlikely, but this could fail, setting
errno.  We even check the case that it fails with EINTR.

If it does set errno, then it has potentially blown away the value or
errno that the preempted code cared about (ie: if the signal arrived
shortly after a system call but before errno was checked).

Wrap the handler with code to save errno.

https://bugzilla.gnome.org/show_bug.cgi?id=741791

Win32: Port Directory Monitoring to New GLocalFileMonitor

This WIP patch moves the Windows Directory Monitoring code to the new
GLocalFileMonitor mechanism, and adds file monitoring in the process.

Progress from previous patch:
-File renames are now properly supported, but G_FILE_MONITOR_EVENT_MOVED_IN
 and G_FILE_MONITOR_EVENT_MOVED_OUT needs to be investigated, as
 ReadDirectoryChangesW() seems to send FILE_ACTION_REMOVED when a file is
 moved out of a directory.
-Events are handled for both the long and short (8.3) variants of the
 filenames, and files monitored will report changes when it is changed
 via its short or long filenames.

Things to be done:
-Perhaps find out about attribute changes in files in a monitored
 directory; if a file is monitored, attribute changes are correctly
 handled.
-Investigate on G_FILE_MONITOR_EVENT_MOVED_OUT,
 G_FILE_MONITOR_EVENT_MOVED_IN, G_FILE_MONITOR_EVENT_PRE_UNMOUNT,
 G_FILE_MONITOR_EVENT_UNMOUNTED.
-Investigate on the "boredom" algoritm, and see how we can do it on
 Windows.

https://bugzilla.gnome.org/show_bug.cgi?id=730116

file monitors: rewrite FAM file monitor

Completely rewrite the FAM file monitor.  Major changes:

 - now runs in the worker thread

 - dispatches events in a threadsafe way via GFileMonitorSource

 - uses unix fd source instead of a GIOChannel

 - is now simple enough to fit into one short file

fen: remove Solaris file monitor support

This code is unmaintained and we have no way to port it to the new file
monitoring API.

kqueue backend: port to new GLocalFileMonitor API

This is the bare minimal effort.  This seems not to crash immediately,
but it definitely needs some better testing.

The backend is not in good shape.  It could use some serious work.

GPollFileMonitor: use thread default main context

Attach the GPollFileMonitor to the thread default main context instead
of the global default.

This matches the behaviour of the other file monitors.

inotify: implement "boredom" algorithm

Use the "interesting" value from g_file_monitor_source_handle_event() to
decide if we're currently being flooded by a stream of boring events.

The main case here is when one or more files is being written to and the
change events are all being rate-limited in the GFileMonitor frontends.

In that case, we become "bored" with the event stream and add a backoff
timeout.  In the case that it is exactly one large file being written
(which is the common case) then leaving the event in the queue also lets
the kernel perform merging on it, so when we wake up, we will only see
the one event.  Even in the case that the kernel is unable to perform
merging, the context switch overhead will be vastly reduced.

In testing, this cuts down on the number of wake ups during a large file
copy, by a couple orders of magnitude (ie: less than 1% of the number of
wake ups).

GFileMonitorSource: return "interesting" value

Return an "interesting" boolean from the event handler function on
GFileMonitorSource.

An event was "interesting" if it will result in a signal actually being
dispatched to the user.  It is "uninteresting" if it only hit an
already-dirty rate limiter.

We will use this information to do some backing off in the backends when
faced with a flood of uninteresting events.

inotify: send CHANGES_DONE when new files 'appear'

We generally assume that an IN_CREATE event is the start of a series of
events in which another process is doing this:

  fd = creat (...)         -> IN_CREATE
  write (fd, ..)           -> IN_MODIFY
  write (fd, ..)           -> IN_MODIFY
  close (fd)               -> IN_CLOSE_WRITE

and as such, we use the CHANGES_DONE_HINT event after CREATED in order
to show when this sequence of events has completed (ie: when we receive
IN_CLOSE_WRITE when the user closes the file).

Renaming a file into place is handled by IN_MOVED_FROM so we don't have
to worry about that.

There are many other cases, however, where a new file 'appears' in a
directory in its completed form already, and the kernel reports
IN_CREATE.  Examples include mkdir, mknod, and the creation of
hardlinks.  In these cases, there is no corresponding IN_CLOSE_WRITE
event and the CHANGES_DONE_HINT will have to be emitted by an arbitrary
timeout.

Try to detect some of these cases and report CHANGES_DONE_HINT
immediately.

This is not perfect.  There are some cases that will not be reliably
detected.  An example is if the user makes a hardlink and then
immediately deletes the original (before we can stat the new file).
Another example is if the user creates a file with O_TMPFILE.  In both
of these cases, CHANGES_DONE_HINT will still eventually be delivered via
the timeout.

substantially rework file monitors

Remove all event merging and dispatch logic from GFileMonitor.  The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.

Get rid of GLocalDirectoryMonitor.  We will use a single class,
GLocalFileMonitor, for both directory and file monitoring.  This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).

Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism.  Put it in GLocalFileMonitor.  All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.

Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor.  All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.

Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor.  gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.

Expose g_local_file_is_remote() internally for NFS detection.

With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c

Port the inotify backend to adjust to the changes above.  None of the
other backends are ported yet.  Those will come in future commits.

inotify: rewrite inotify-kernel

Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.

Events are now reported as soon as is possible instead of after a
delay.

We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed.  We
limit ourselves, however:

 - no more than 100 events can be delayed at a time

 - no event can be delayed by more than 10ms

https://bugzilla.gnome.org/show_bug.cgi?id=627285

GLocalFile: add _new_from_dirname_and_basename

Add a new internal constructor for GLocalFile (which itself is private).

This new constructor allows creating a GLocalFile from a dirname and a
basename, assuming that the dirname is already in canonical form and the
basename is a regular basename.

This will be used for creating GLocalFile instances from the file
monitoring code (for signal emissions).

Finnish translation update

Updated Norwegian bokmål translation.

Update .gitignore

Updated Hebrew translation

bump version (to GLib 2.45.0)

GLib 2.43.92

Updated Russian translation

Updated Slovenian translation

Updated French translation

Translation pa updated for Gnome

ContextSpecificGroup: some fixups

For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.

Fix that up.

Also: fix some overzealous asserting in the testcases.  Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.

Updated Bosnian translation

Updated Swedish translation

goption: Mention type of G_OPTION_ARG_CALLBACK in documentation

threads: use FUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE if possible

This avoids some expensive code paths in the kernel, see
http://lwn.net/Articles/229668/

https://bugzilla.gnome.org/show_bug.cgi?id=741442

docs: clean up a few glib issues

Fix a few typical problems, and also stop wrapping the inline definition
of g_steal_pointer in parens, since it is not necessary and it confuses
gtk-doc.

gio docs: remote errant colon from docstring

This does not belong there.

Convert remaining uses of 'Rename to:'

This was replaced by (rename-to) in 2013 (see bug 676133).

They're also causing gtk-doc trouble, so let's get rid of them.

docs: more cleanups for GIO

Doc: Fix missing API from GOptionGroup boxing

Doc: Mark a few things as private

Win32: Move g_win32_check_windows_version() to the correct place in header

It was added after G_END_DECLS, outside the #ifdef G_PLATFORM_WIN32,
and inside a #ifndef __GTK_DOC_IGNORE__ block. So it was missing from
the doc.

https://bugzilla.gnome.org/show_bug.cgi?id=743661

Updated Latvian translation

Updated Korean translation

Updated Greek translation

Update Catalan translation

Updated German translation

Updated POTFILES.in

gtask: Add a GTask:completed property

This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.

Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.

https://bugzilla.gnome.org/show_bug.cgi?id=743636

Updated Bulgarian translation

Updated Slovak translation

Updated Vietnamese translation

Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>

Updated Spanish translation

Updated Lithuanian translation

Updated Kazakh translation

Updated Hungarian translation

Updated Italian translation

Updated Polish translation

Updated POTFILES.in

Updated Korean translation

GSocketClient: fix handling of application proxies

g_socket_client_add_application_proxy() claimed "When the indicated
proxy protocol is returned by the #GProxyResolver, #GSocketClient will
consider this protocol as supported but will not try to find a #GProxy
instance to handle handshaking." But in fact, it did the checks in the
wrong order, so GProxy proxies ended up overriding
application-specified ones. Fix that.

Also, simplify the code a bit by making use of g_hash_table_add() and
g_hash_table_contains().

https://bugzilla.gnome.org/show_bug.cgi?id=733876

HTTP proxy support

Based on code from "WockyHttpProxy" written by Nicolas Dufresne
and Marc-André Lureau. Initial glib patch by Brian J. Murrell.

https://bugzilla.gnome.org/show_bug.cgi?id=733876

Windows: Use Standard Networking Functions If Possible

Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time.  On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init().  Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.

This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.

https://bugzilla.gnome.org/show_bug.cgi?id=730352

gfdonotificationbackend: support themed icons

The spec allows setting the "image-path" hint to an icon name as well.

https://bugzilla.gnome.org/show_bug.cgi?id=745634

gresolver.c: Windows: Fix IPv6 Address Handling

Check the IPv6 addresses on Windows, as we need to reject those that have
brackets/ports around them as valid addresses in this form would have been
accepted during the call to g_inet_address_new_from_string ().

https://bugzilla.gnome.org/show_bug.cgi?id=730352

gio: add some missing autocleanup

https://bugzilla.gnome.org/show_bug.cgi?id=745589

Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>

MSVC Builds: Few More Enahncements

Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn
helper programs), so that they match the names of the DLLs/EXEs that are
built.  Also update the .lib generation so that all will use -$(ApiVersion)
from the property sheets instead of the -2.0 which was previously hard
coded (as we will eventually move into GLib 3.x in the future, for example)

gobject: Mark a helper variable as const

It’s only used for argv values, which are not modified here.

https://bugzilla.gnome.org/show_bug.cgi?id=614684

gerror: Minor clarifications to the GError documentation

 • Clarify that GError** parameters are for the return of _newly
   allocated_ GError*s.
 • Clarify that errors may need to be checked for explicitly if the
   return value of a function doesn’t reliably indicate them.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

Updated Serbian translation

gvariant: Use ‘UTF-8’ in docs rather than ‘utf8’

Nitpicky correction.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

gmain: Explicitly document the threading behaviour of g_timeout_add()

i.e. That calling g_timeout_add() from a thread other than the main one
probably doesn’t do what you want. Same for g_idle_add() and the
*_full() variants.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

gobject: Mention g_clear_object() in g_object_unref() documentation

https://bugzilla.gnome.org/show_bug.cgi?id=741779

gmem: Clarify that a NULL check is not needed before calling g_free()

It was documented before, but wasn’t especially clear. Doing
    if (X)
        g_free (X);
is apparently quite a pervasive real-world anti-pattern, so perhaps it
could be documented more explicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

glist: Clarify that g_list_nth() is expensive

Just in case people have forgotten their basic algorithms course. Seen
in some pretty terrible code in the wild; hopefully mentioning the cost
in the documentation will make people think twice about using a counter
variable when iterating over a linked list.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

glist: Clarify how g_list_free_1() handles links

It doesn’t, which is fine, but could be unexpected if undocumented.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

ghash: Document that g_hash_get_[keys|values]() are expensive

And definitely not the right way to iterate over a hash table (as seen
in code in the wild).

https://bugzilla.gnome.org/show_bug.cgi?id=741779

gparamspecs: Recommend use of most specific GParamSpec types

It’s quite common to see a g_param_spec_pointer() used for GObject or
boxed types which, while not incorrect, does make memory management
unsafe, since no copying or reference counting can be performed
automatically.

Similarly, people often use g_param_spec_boolean() when an enum would be
more appropriate, cf.
    http://blog.ometer.com/2011/01/20/boolean-parameters-are-wrong/
Using enums also means that the set of allowable values can be extended
in future if needed.

In the hope that people who write code like that read the documentation,
mention the more specific types in the documentation.

https://bugzilla.gnome.org/show_bug.cgi?id=741779

docs: Expand introduction to mention using async calls over sync ones

As discussed on the mailing list (see the whole thread):
    https://mail.gnome.org/archives/desktop-devel-list/2015-February/msg00126.html

Expand the GIO documentation introduction to talk a little about when to
use async and sync functions, and how the former should almost always be
preferred over the latter.

Link to this from the GFile documentation, which is an entry point for a
lot of async calls.

https://bugzilla.gnome.org/show_bug.cgi?id=744722

gstring: Mark the return value from g_string_free() as nullable

It’s NULL iff free_segment is TRUE, so the annotation doesn’t quite
capture all the function definition, but is a safe over-estimate of the
return value’s nullability.

https://bugzilla.gnome.org/show_bug.cgi?id=719966

gfileutils: Mark the return value from g_path_skip_root() as nullable

It returns NULL for non-absolute paths.

https://bugzilla.gnome.org/show_bug.cgi?id=719966

docs: Remove redundant header examples from GObject tutorial

These are in the header boilerplate section, but are actually source
boilerplate which is covered in later sections.

https://bugzilla.gnome.org/show_bug.cgi?id=744060

docs: Change tutorial encodings from ISO-8859-1 to UTF-8

ISO-8859-1 — that’s a blast from the past.

https://bugzilla.gnome.org/show_bug.cgi?id=744060

Visual Studio Builds: "Install" .pdb files

They are helpful in debugging in a stack.

MSVC Builds: GIO: Standardize zlib Linking

Link to zlib1.lib for all builds, as:
-The notion of zlib1d.lib is rather not standardized across the board for
 most cases.
-Easier for the grand all-in-one solution file.

Visual Studio 2008 Builds: Speed Up Release Builds

Use the /MP option so that each project can build multiple sources in
parallel, which can cut down release build times by quite a bit.  This will
cause a brief warning for debug builds due to their use of /Gm, and builds
would otherwise proceed as they did before.

Unfortunately Visual Studio 2008 is too old to support the /d2Zi+ flag, so
we can't make a better debug situation for it at the moment.

MSVC Builds: Improve Build Speed and Debugging

Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.

These are only applicable for Visual Studio 2010/2012 and later.

MSVC Builds: Fix and Update "Installation"

The gobjectnotifyqueue.c was accidently dropped from the files to copy, and
a new public header for GIO was added, so address these parts.

Updated Czech translation

GContextSpecificGroup: fix deadlock

There was a theoretical deadlock between the worker trying to emit a
signal at the same time as we were waiting for it to shutdown the
notification (while holding the lock).

The deadlock was particularly annoying because we didn't really need to
wait for the shutdown and because it wasn't possible to signals to
arrive while waiting for a start.  Attempting to deal with start and
stop in an asymmetric way could have lead to other weird situations,
however.

Drop the lock while waiting for the worker thread to start.  This means
that we face the possibility of multiple waiters on the cond at the same
time, so we need to make more of a state machine.

https://bugzilla.gnome.org/show_bug.cgi?id=742599