| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
signal is all we need since we only have one waiter and
likely faster
git-svn-id: https://svn.musicpd.org/mpd/trunk@7349 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
| |
|
|
|
| |
Oops, forgot to unlock a mutex
git-svn-id: https://svn.musicpd.org/mpd/trunk@7348 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
|
The select() in the main event loop blocks now (saving us many
unnecessary wakeups). This interacted badly with the threads
that were trying to wakeup the main task via
pthread_cond_signal() since the main task was not blocked
on a condition variable, but on select().
So now if we detect a need to wakeup the player, we write
to a pipe which select() is watching instead of blindly
calling pthread_cond_signal().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7347 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
