[pulseaudio-discuss] pa_fdsem racy?

[Daniel Mack]

Can anyone help resolve this?

On Tue, Dec 01, 2009 at 01:34:11PM +0100, Daniel Mack wrote:
> 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
> 
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss