[pulseaudio-discuss] Threaded loops and theoretical deadlock in reference implementation (and lots of code).
lennart at poettering.net
Sun Mar 1 01:40:33 PST 2009
On Sun, 01.03.09 02:27, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 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:
> 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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss