Gentlemen, while debugging more details about the Mac OS X port of pulseaudio, I constently stumble over more and more things that demand attention. One thing is that poll() is entirely broken on Mac OS X and causes the CPU to suck 100% load because the timeout parameter is ignored. I fixed that already by enabling the legacy 'poll via select' workaround that has been in the PA tree for a long time (and originally for Windows). Will post patches soon. But even with that workaround enabled, the PA daemon often fails to start with a command line as simple as $ ./pulseaudio -vvn -L module-null-sink -C The above should bring me to an interactive prompt, but it doesn't, at least not always. When debugging that, I always find a thread hung in read(), caused by the pa_fdsem code. This execution path waits for some user of a pa_fdsem to call pa_fdsem_post(). I suspect this implementation to be racy, but I might have not understood the sematic of this data type. Is a pa_fdsem supposed to be accessed by more than one reader/writer? I wrote a little test which shows that the latter does not work reliably: https://gist.github.com/1e8ba0dc00c94a05c090 I would expect thread #0 to eat one of the two references it posted, so there is one free for thread #1. However, this test only ever succeeds if thread #1's wait() happens to be called right between the two posts in thread #0. IOW, it mostly fails and hangs. Can anyone explain whether this is a bug or if I'm digging at the wrong place? While the plain logic behind all this is fairly simple, I'm just not aware of how things are supposed to work in PA. Thanks, Daniel
