On linux-rt, kernel IRQ threads are configured with priority=50, and
this change configures MPD somewhat below that priority, leaving some
room for other programs to be configured in between.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/643
On Windows, we keep using our own implementations, because GCC
implements std::mutex and std::condition_variable with pthread
emulation, which is not a good choice.
Since we switched from autotools to Meson in commit
94592c1406, we don't need to include
`config.h` early to properly enable large file support. Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.
This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.
So long, autotools! This is my last MPD related project to migrate
away from it. It has its strengths, but also very obvious weaknesses
and weirdnesses. Today, many of its quirks are not needed anymore,
and are cumbersome and slow. Now welcome our new Meson overlords!
Some Audio plugin (such as ALSA, and soon CoreAudio) already support microsecond level buffer time. However, current interval less than 1000 microseconds will cause a bug that the code treated as 0 ms.
There is a POSIX definition for sched_setscheduler(), but Linux does
not implement that; instead of changing the process's scheduler, it
only affects one thread. This has caused some confusion among
application developers and C library developers.
While glibc implements Linux semantics, Musl has made their
sched_setscheduler() function an always-failing no-op, causing the
error message "sched_setscheduler failed: Function not implemented".
http://git.musl-libc.org/cgit/musl/commit/src/sched/sched_setscheduler.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2
Instead of relying on the C library which may be unreliable here, we
now roll our own system call wrapper.
Closes#218
This attribute shall be used only for IsInside() to make this safe
against a race condition described in #188:
> There is no requirement on the implementation that the ID of the
> created thread be available before the newly created thread starts
> executing.
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_create.html):
This means that on some pthread implementations (e.g. Haiku), the
assert(thread.IsInside()) could fail.
Closes#188
Use the "==" operator instead of pthread_equal().
This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.
Use the "==" operator instead of pthread_equal().
This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.
