[pulseaudio-discuss] Threaded loops and theoretical deadlock in reference implementation (and lots of code).

[Lennart Poettering]

On Sun, 01.03.09 02:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Hi,
>
> I was trying to debug a deadlock while using gvim (with  
> libcanberra+pulse output: https://qa.mandriva.com/show_bug.cgi?id=44925)  
> I had reason to read the threaded loop docs.
>
> The reference implementation shown here:
> http://0pointer.de/lennart/projects/pulseaudio/doxygen/threaded_mainloop.html#basic_subsec
>
> In my mind, the operation could theoretically be cancelled and this the  
> _get_state() will return PA_OPERATION_CANCELLED.
>
> In the example code, if this happens, the loop will spin and the main  
> loop will never be unlocked.
>
> This could be fixed by spinning when the state is PA_OPERATION_RUNNING  
> rather when it is not PA_OPERATION_DONE (incidentally, there is a typo  
> in the docs... it says OPERATION_RUNNING without the PA_ prefix...).
>
> Anyway, any comments on this observation would be appreciated.

PA_OPERATION_CANCELLED is a state that is only entered after the
*client* called pa_operation_cancel(), i.e. it needs to be triggered
from the same code that waits for pa_operation_get_state() becoming
PA_OPERATION_DONE. Hence waiting for _DONE is actually safe.

That said it is probably still more robust if we'd only loop as long
as _RUNNING is the current state so that this loop properly exits
should the client code be eventullay changed to call _cancel
somewhere. I have now changed this in my local git tree here.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4