[pulseaudio-discuss] deadlocks when running pulseaudiowith --high-priority=1

[Kai.Vehmanen at nokia.com]

Hi,

On 18 Dec 2007,  Lennart Poettering wrote:
>> - run pulseaudio (self-compiled, debian stable) with
--high-priority=1
>> - first client: while [ 1 ] ; do aplay -D pulse foo.wav ; done
>> - second: while [ 1 ] ; do aplay -D pulse foo.wav ; done
>
>Uh, doesn't happen here.

maybe contents of foo.wav makes a difference. For me, the most 
reliable way to reproduce the bug is:

- run pulseaudio at 48kHz
- pick foo.wav of 44.1kHz
- replace second client with paplay

Oh well, it seems like a rare corner case, as it seems to occurs
with only certain combinations even in my setup.

>Could you please paste the whole backtrace somwhere?

I added traces to the ticket:
http://www.pulseaudio.org/ticket/195

>> I made a fix in my local tree which uses pa_mutex_trylock() (a new 
>> funtion implemented using pthread_mutex_trylock()) and nanosleep()
>
>Uh? That mutex does priority inheritance anyway. If you get a 
>lockup than there's something wrong with the locking order, 
>it's most likely not a prio inversion problem.

Aa, ok, I hadn't realized that PTHREAD_PRIO_INHERIT is now available
on Linux (and used by PA code). In the traces, the SCHED_FIFO thread is
blocked on pthread_mutex_lock() while the SCHED_OTHER thread
is blocked on sem_wait() (called from pa_asyncmsgq_send()).

br,
-- 
first.surname at nokia.com (Kai Vehmanen)