[pulseaudio-discuss] Making module-zeroconf-publish non-blocking

[Arun Raghavan]

On Wed, 2013-05-15 at 13:05 +0300, Tanu Kaskinen wrote:
> On Wed, 2013-05-15 at 10:13 +0530, Arun Raghavan wrote:
> > Hello,
> > This one is really intrusive (at least to m-z-publish), but deals with a
> > long-standing bug which is also a 4.0 blocker[1] where PulseAudio sometimes 
> > takes 20s for daemon startup to complete.
> 
> There's no evidence that module-zeroconf-publish has anything to do with
> 58758.

I can reproduce intermittent ~20s startup delays that are clearly in
module-zeroconf-publish, which is why I introduced this as a fix for it.

It's easy enough to reproduce, just run this in a few times and see when
m-z-publish gets loaded. avahi-daemon needs to not be running.

    pulseaudio -vvvv 2>&1 | grep zeroconf

> If the 20s delay is caused by some D-Bus message timing out, have you
> investigated what message is timing out and why? I don't think it's

It's a ping message to the Avahi daemon (which is not running), and the
timeout takes this long. The relevant code is:

http://git.0pointer.de/?p=avahi.git;a=blob;f=avahi-client/client.c#l564

> expected behaviour, so fixing this in PulseAudio is working around a bug
> elsewhere. I support any patches that remove blocking IO from the main

The default timeout is 25s. So a long block is not unexpected. However,
I don't see the timeout take this long every time. I'm trying to find
out why this is.

> thread, though, so I'm fine with having the fix anyway, but pushing it
> to master at this point doesn't seem justified (not a regression, and
> the bug impact seems very limited).

This bug's been open downstream for 6 months now, and is biting a number
of users, so I'd like to address fixing it (which is also why I'd marked
it as a 4.0 blocker in the first place).

-- Arun