GKeyFile: improve introspection annotations

Ensure that all methods that take or return arrays are annotated
(including length). Mark ref, unref and free methods as (skip).

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

Turn GKeyFile into a boxed for introspection

Using the new refcounting API, introduce a boxed type wrapping
GKeyFile and expose it introspection bindings in glib-types.h.

GKeyFile: Add refcounting API

Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.

Based on the patch by Christian Persch and Emmanuele Bassi.

Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808

Add 'Since 2.32' indexes to gio and gobject docs

GAppLaunchContext: add environment-manipulating functions

Add functions for manipulating the environment under which a
GAppLaunchContext will launch its children, to avoid thread-related
bugs with using setenv() directly.

FIXME: win32 side isn't implemented yet

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

Misc doc formatting fixes

Add tests for new g_environ_ functions

Move environment-related functions into their own files

gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.

The private _g_getenv_nomalloc has been moved to its sole caller.

gutils: Add functions for working with environment arrays

When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.

So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.

http://bugzilla.gnome.org/show_bug.cgi?id=659326

Add to the pitfalls: fork() and daemon()

tests/Makefile.am: remove unused LDFLAGS variable

Expand thread docs a bit

Add some discussion of pitfalls of threaded programming.

Documentation tweaks

Updaged Galician translations

Check for "our" threads in some places

Don't allow g_thread_join() to be called on or g_thread_exit() to be
called from within threads that were not created by GLib.  Document
this.

gtk-doc g_thread_ref() and g_thread_unref()

Rename g_thread_try to g_thread_try_new

Add atomic test to TEST_PROGS

Documentation additions

Improve test coverage

Add a test involving g_thread_ref/unref

Also, fix the resource-limit test to properly unset RLIMIT_NPROC.

Add g_thread_try to the docs

Update doc lists

Minor doc clarifications

Mention thread API changes in README

I read the news today, oh boy...

Stop checking for fork() across GMainContext

01ed78d525cf2f8769022e27cc2573ec7ba123b3 introduced assertion checks for
creating a main context, forking, and attempting to use the main context
from the child side of the fork.

Some code (such as gnome-keyring-daemon) daemonise after calling
GMainContext.  That's probably still mostly safe since we still only
have one side of the fork touching the context afterwards.

This use case is still troubling, however, since if any worker threads
have been created at the time of the fork(), we could end up in the
classic situation of leaving some mutexes in a locked state when the
other threads disappear from the copy of the image that the child gets.

This will require some deeper thinking...

Mask all signals in GLib worker thread

Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.

The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).

If we mask all the signals in our worker, then this can't happen.

desktop-app-info: Add support for X-GNOME-Keywords

With search gaining traction as being the preferred way to locate
applications, the existing .desktop file fields meant for browsing
often produce insufficient results.
gnome-control-center introduced a custom X-GNOME-Keywords field for
that purpose, which we plan to support in gnome-shell as well.

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

g_cond_timed_wait: support NULL time parameter

It was undocumented, but this used to mean "wait forever".  Looks like
we have some uses of this internally and there may be others in the
wild...

GCond: use monotonic time for timed waits

Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().

Deprecate the old API based on wallclock time in a GTimeVal.

Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.

tests: disable deprecation warnings for tests

We need to test deprecated functions, so don't warn us for doing so.

gutils: stop using GStaticPrivate

This was our last internal use.

Revert "make struct _GThread private"

This reverts commit d904612100120d12126f1a6623a106d8a5b02fa6.

glibmm touches the contents of GThread, so this broke their build.

make struct _GThread private

Hide the definition of struct _GThread in gthreadprivate.h for now.

This is possibly an API break -- although the structure contents were
undocumented and it was not safe to access them in a meaningful way,
someone may have tried to do it anyway.  We'll leave it here for a while
to see if it causes any problems.

Avoid merging its contents with GRealThread for now, just incase we need
to expose it again.

tidy up gthreadprivate.h

Remove some unused includes, too.

drop g_thread_new_full()

We'll hold out on this until someone has a really convincing reason for
why they need to control the stack size.

If we do decide to add it back, it should probably have a name like
_new_with_stack_size(), not _full().

g_thread_new: never fail

Remove the GError argument from g_thread_new() and abort on failure.
Introduce g_thread_try() for those who want to handle failure.

thread: nuke the concept of 'joinable'

And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().

Change the wording in the docs.  Clarify expectations for
(deprecated) g_thread_create().

GThread: make refcounting public

thread: simplify 'free' process

GThread is freed using some very slightly confusing logic: if the thread
was created 'joinable', then the structure is freed after the join()
call succeeds (since we know the thread has exited).  If the thread was
not created 'joinable' then the free is when the thread quits (since we
know 'join' will not be called later).

Move to a straight ref-counting system: 1 ref owned by the thread and 1
extra ref if the thread is joinable.  Both thread quit and joining will
decrease the refcount by 1.

remove 'joinable' parameter to backends

Both backends are now oblivious to the concept of joinability, so don't
bother passing the parameter.

posix threads: joinable tweaks

Make the POSIX backend a little bit more like the win32 one in terms of
how we deal with joinability.

Calling g_system_thread_join() is now optional, and
g_system_thread_wait() can be safely called by multiple threads.

There is no longer any internal concept of joinability.

tests: don't #include <sys/resource.h> on win32

win32 threads: simplify

Merge the GThreadData with the GThreadWin32 struct.  Drop the extra TLS
variable.

Close the handle on _free(), which means that there is no leak if
g_system_thread_join() isn't called.

Remove all internal concept of joinability.

Only g_system_thread_free() our own threads

Keep track of if we created a thread for ourselves or if the GThread*
was allocated in response to g_thread_self() on a previously-unknown
thread.

Only call g_system_thread_free() in the first case.

Finish killing off GSystemThread

win32 threads: use our own data, not system_thread

Stop using the generic system_thread field in GRealThread.  Use our own
pointer instead.

win32: fix function name clash

posix threads: use our own system_thread

Wrap GRealThread in a GThreadPosix that includes its own pthread_t field
called "system_thread" and use that instead of the generic field in
GRealThread.

thread creation: Simplify error handling

Instead of always returning non-NULL and finding out about errors via
the GError*, return NULL from the backend in the event of an error.

Combine g_sytem_thread_{new,create}()

g_system_thread_create: drop 'data' arg

Since it's now always the same as the 'thread' arg.

g_system_thread_create: SystemThread -> RealThread

Just like g_system_thread_wait().

Move more docs inline

g_system_thread_join: rename to _wait()

g_system_thread_join: take GRealThread *

Make g_system_thread_join take the GRealThread* instead of a
GSystemThread.

thread: delegate allocation of GThread to backends

Add g_system_thread_new() and g_system_thread_free(), implemented with
GSlice.  Use those instead of g_new() and g_free().

Presently, the backends are both doing the same thing.  This will change
soon.

Move GScanner docs inline

thread: stop sharing g_once_mutex

Unrelated code shouldn't be sharing the same mutex for no good reason --
particularly not across a file boundary.

thread: drop thread setup function hackery

Use a custom proxy function for the deprecated case instead.

Now GRealThread has strictly zero members dedicated to deprecated
functionality.

Deprecate GCache

Ryan said it would be 'deprecated soon in GLib', when he removed
the use of this in GTK+. That was a year ago, so its about time
we act on it.

thread: Delete g_system_thread_self()

It's no longer used for anything at all.

thread: reduce use of system_thread

The use of system_thread is now limited to joining.  We don't do that
for threads that we didn't create for ourselves, so we don't need to
call g_system_thread_self() to fill in system_thread for those.

thread: hide g_static_rec_mutex_get_rec_mutex_impl

Unlike with GStaticMutex, this function was never part of the pre-2.32
ABI, so we should keep it tucked in.

missed from last commit

thread: remove GSystemThread assign/equal

These are no longer in use.

thread: remove dead decl from gthreadprivate.h

This function hasn't existed for a while...

thread: Remove the zero_thread

This was only used for redundant assertion checks.

GStaticRecMutex: implement via GRecMutex

Instead of doing our own hacked-up version.

This also reduces use of GSystemThread.

thread: use GSList for g_thread_foreach list

...instead of having a 'next' pointer in the GThread struct.

Now GThread contains no fields used only by deprecated code (except for
the rather generic setup function field).

thread: call g_enumerable_thread_add via callback

There are no longer any functions defined in gthread-deprecated.c called
from gthread.c.

thread: use GPrivate for enumerable threads

Use a GPrivate to track the destruction of enumerable threads and remove
them from the list.

gvariant: Doc typo fix

gvariant: Briefly mention limits

gthread-deprecated: add a mising "static" to a method

giomodule: make the default_modules mutex recursive

It is possible for _g_io_module_get_default() to be called recursively
(eg, if a module of one type is loaded that tries to look up gsettings
from its init() method and ends up causing the gsettings module to be
loaded). So use a recursive mutex.

Simplify checks for CLOCK_MONOTONIC

Remove the complicated configure-time and runtime checks, and just use
CLOCK_MONOTONIC if it's defined.

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

Disable deprecations where appropriate in tests

Disable deprecations where appropriate in tests

Make single includes mandatory

This has been the official line since 2.17, which seems plenty
long enough for a transition phase.

GStaticPrivate: implement via GPrivate

Thanks to the modifications in 3d4846d92309d001697c2827660fa41b5c63dbc4,
GStaticPrivate is not so directly tied in with GThread anymore.  It is
now a simple matter to cut it out completely by using a GPrivate to
store the GArray instead of storing it in the GThread.

Update deprecation docs

Silence deprecations in deprecated/ (again)

Update VS projects

Get rid of _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_WARNINGS
from the preprocessor definitions as those two macros are now defined
in msvc_recommended_pragmas.h, which is force-included in these projects
via the property sheets.  This will silence C4005 warnings on macro
redefinition.

Bug 661438: Update msvc_recommended_pragmas.h

Don't disable warning C4996 as that is the Visual C++ warning triggered by
__declspec(deprecated) and __declspec(deprecated('..."))-disabling that
warning will defeat the purpose of G_DPRECATED/G_DEPRECATED_FOR.

For people who don't want to see the GLib deprecation warnings during GLib
compilation, define GLIB_DISABLE_DEPRECATION_WARNINGS in the projects or
property sheet.

Bug 661438: Fix up gmacros.h a bit

The macro here should be G_DEPRECATED, not G_GNUC_DEPRECATED.

Update VS property sheets

Missed the new glib/gstringchunk.h header that needed to be installed as
well.

g_time_val_from_iso8601: clarify the docs a bit

gmain: use GPrivate instead of GStaticPrivate

Fix two tests for G_DEBUG=gc-friendly

Use GLIB_DEPRECATED instead of G_GNUC_DEPRECATED in our headers

This will let others opt out of seeing GLib deprecation warnings
by defining GLIB_DISABLE_DEPRECATION_WARNINGS.

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

Add our own deprecation macros

This will allow to suppress deprecation warnings on a per-module
basis, if needed. They are on by default now, though.

Add better deprecation macros

Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.

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

Update VS property sheets

Copy the deprecated headers in their appropriate places.

glibconfig.win32(.in): Cleanup cruft

The definitions of _GMutex* and G_STATIC_MUTEX_INIT is now found in
glib/deprecated/gthread.h, and should no longer be in the mainline
code, so remove them from here.

GStaticMutex: ABI fixup

Everything was OK as long as GMutex was backed by pthread_mutex_t on
POSIX.  Since this is no longer the case, the ABI of GStaticMutex was
broken.

Fix that up by using pthread_mutex_t directly in the structure.  Since
that's potentially incompatible with our GMutex implementation, set
g_thread_use_default_impl to FALSE to cause the fallback code (which
manually allocates a GMutex) to run, even in the case of
already-existing code (without the need for a recompile).  This will
cause the pthread_mutex_t part of the struct to be completely ignored.

Compile private test with -pthread on UNIX

We are using explicit pthread calls here, so we should
use the right linker flags for that.

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

Don't use deprecated GThread API in gio tests

Updated Norwegian bokmål translation