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

[Lennart Poettering]

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

>> 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.

I'd need a full backtrace (over all threads!) to say something. The
bugzilla report only contains bts for one trhead.

Lennart

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