Replaced all occurrences of g_error() with MPD_ERROR() located in a new header
file 'mpd_error.h'. This macro uses g_critical() to print the error message
and then exits gracefully in contrast to g_error() which would internally call
abort() to produce a core dump.

The macro name is distinctive and allows to find all places with dubious error
handling. The long-term goal is to get rid of MPD_ERROR() altogether. To
facilitate the eventual removal of this macro it was added in a new header
file rather than to an existing header file.

This fixes #2995 and #3007.

I've added PIPE_EVENT_SHUTDOWN because calling g_main_loop_quit() do not work when called from another thread.
Main thread was sleeping in g_poll() so I needed some way to wake it up.

By some strange reason call close(event_pipe[0]) in event_pipe_deinit() hangs.
In current implementation that code never reached so that was not a problem :-)
I've added a conditional to leave event_pipe[0] open on Win32.

For some unknown reason, read() blocks on WIN32, even though it was
invoked inside the G_IO_IN callback.  By switching to GIOChannel
functions, this problem is solved, and it works on both Linux and
Windows.

On WIN32, use g_io_channel_win32_new_fd() instead of
g_io_channel_unix_new().  There doesn't seem to be a practical
difference, but it seems more correct.

After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.

Changed the wrappers for pipe(), socket(), accept().  On WIN32, this
does not work for pipe().

Added the "fd_util" library, which attempts to use the new thread-safe
Linux system calls pipe2(), accept4() and the options O_CLOEXEC,
SOCK_CLOEXEC.  Without these, it falls back to FD_CLOEXEC, which is
not thread safe.

This is particularly important for the "pipe" output plugin (and
others, such as JACK/PulseAudio), because we were heavily leaking file
descriptors to child processes.

On both locations, the result of write() can be ignored safely.  In
event_pipe_emit_fast(), that can only be "EAGAIN", which means that
the pipe buffer is full - no further notification required.  In
client_init(), that would be a fatal connection error, which would be
caught by the next event.

This patch fixes gcc warnings.

This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.

Define the GLib logging domain in the following libraries: conf,
daemon, event_pipe, log.

Free memory before exiting.

Removed all allocation functions, xwrite(), xread(), ARRAY_SIZE().
Those have been superseded by GLib.

xclose() aims to be the signal safe version of close(). However during
cleanup, this isn't important.

Windows has no pipe(), it only has _pipe() with two additional
parameters.

There is only one location using PIPE_EVENT_SIGNAL: to synchronize
player_command() with player_command_finished().  Use the "notify"
library instead of the event_pipe here.

event_pipe_emit_fast() is aimed for use in signal handlers: it doesn't
lock the mutex, and doesn't log on error.  That makes it potentially
lossy, but for its intended use, that does not matter.

Make the event_pipe (formerly main_notify) send/receive a set of
events, with a callback for each one.

The default event PIPE_EVENT_SIGNAL does not have a callback.  It
is still there for waking up the main thread, when it is waiting for
the player thread.

Continuing the previous patch.

We are going to migrate away from the concept of notifying the main
thread.  There should be events sent to it instead.  This patch starts
a series to implement that.

These functions are not used anymore since we use the GLib main loop.

This is a rather huge patch, which unfortunately cannot be splitted.

Instead of using our custom ioops.h library, convert everything to use
the GLib main loop.

Currently, both sides of the pipe are blocking, although we do not
need blocking read().  Convert it back to blocking.  Eliminate the
select() from wait_main_task().

To wake up the main thread, don't attempt to use a GCond/GMutex
(struct notify).  This kind of mixed wakeup method has known race
conditions.

The idea behind this patch is: for wakeups which happen while the main
thread is sleeping, use only a pipe.  For wakeups which happen while
the main thread is waiting for the player thread, we can later change
to GCond.  For now, accept the overhead of using a pipe for the
latter.

In the long run, the main thread will never wait for the player
thread, but will do everything asynchronously.

When there are standardized headers, use these instead of the bloated
os_compat.h.

Typedefs shouldn't be used, use the bare struct names instead.

It'll be easier to keep track of what code runs in what
task/thread this way.

There was a known deadlocking bug in the notify library: when the
other thread set notify->pending after the according check in
notify_wait(), the latter thread was deadlocked.  Resolve this by
synchronizing all accesses to notify->pending with the notify object's
mutex.  Since notify_signal_sync() was never used, we can remove it.
As a consequence, we don't need notify_enter() and notify_leave()
anymore; eliminate them, too.

Destroy the mutex when it is not used anymore.

It is legal to call wakeup_main_task() from within the main thread,
e.g. from within a signal handler.  Remove the assertion.

Remove duplicated code.

Avoid some duplicated code in main_notify.c.

The function wait_main_task() is racy: if the function
wakeup_via_cond() sees the mutex is locked just before
wait_main_task() executes pthread_cond_wait(), the main thread blocks
forever.

Work around this issue by adding a "pending" flag just like in my
notify.c code.  A standards-compliant solution should be implemented
later.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7365 09075e82-0dd4-0310-85a5-a0d7c8717e4f

pthread_cond_signal is a no-op if nothing is waiting on it

git-svn-id: https://svn.musicpd.org/mpd/trunk@7351 09075e82-0dd4-0310-85a5-a0d7c8717e4f