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

Colin Guthrie 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:
> 
>> 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.

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?
https://qa.mandriva.com/show_bug.cgi?id=44925

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.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   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 mailing list