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

[Lennart Poettering]

On Tue, 03.03.09 11:17, Colin Guthrie (gmane at colin.guthr.ie) wrote:

>
> 'Twas brillig, and Lennart Poettering at 03/03/09 02:14 did gyre and gimble:
>>> 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.
>
> That is the one and only tread!

Are you sure? That would be weird. None of the dumps in the bug report
shows the output of "info threads", are you really sure there is just
one thread?

libcanberra spawns a background thread to do the sound IO in. It then
uses pthread_cond_wait and similar functions to communicate with
it. You bt shows that you program is waiting in such a
pthread_cond_wait -- however if there no other thread around it will
of course block.

The only reasonable explanation I have for this is that vim fork()s
around all the time. On a fork() the threads are not inherited by the
child processes. The libcanberra context does not deal with this
properly (in fact almost nothing does, not gtk, nobody).

> Like I say, I suspect this is related to the abuse of the gtk main loop  
> entering and exiting and not handling things in a proper multi-threaded 
> way.

I don't think this is a problem. If the sound IO thread went away
(which is what you suggest) then this is unrelated to the gtk event
loop.

Also, libcanberra doesn't rely on the gtk event
loop. canberra-gtk-module does, but all that is necessary is that the
idle callback is called 'eventually'. It doesn't really matter how
quickly that is or whether vim has awkward event loop semantics.

> As I'm not a gtk hacker, I have to ask whether:
>  a) Are single threaded GTK apps supported by GTK?

Sure, of course. 99% of all GTK apps are single threaded.

>  b) Can GTK modules (e.g. libcanberra) detect this and take appropriate  
> action?

Uh?

>  c) Should libcanberra's pulse driver be async rather than blocking so  
> as to work as a GTK module in a single threaded app?

Audio IO should *never* happen from the main event loop.

Lennart

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