[pulseaudio-discuss] Threaded loops and theoretical deadlock in reference implementation (and lots of code).
gmane at colin.guthr.ie
Sun Mar 1 02:31:59 PST 2009
'Twas brillig, and Lennart Poettering at 01/03/09 09:40 did gyre and gimble:
> 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.
Ahh cool. Well that's reassuring to hear as there is a fair bit of code
that uses this approach from what I can tell.
Incidentally, can you have a quick glance over this bug for me?
As I said in my last comment, I'm pretty sure the problem is the abuse
of the gtk main loop (which they exit and restart) but as I'm not really
a gtk hacker I'm not too sure.
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss