[pulseaudio-discuss] Threaded loops and theoretical deadlock in reference implementation (and lots of code).
lennart at poettering.net
Mon Mar 2 18:14:05 PST 2009
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?
> 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 Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss