[pulseaudio-discuss] pa_fdsem racy?

[Daniel Mack]

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