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

[Tanu Kaskinen]

On Wed, 2013-05-15 at 16:02 +0530, Arun Raghavan wrote:
> 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.

Sure, but the logs in 58758 do not have any trace of
module-zeroconf-publish. That makes me pretty sure that the bug that
you're seeing and 58758 are different bugs.

> 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.

I don't think you can draw such conclusion. You could say "so a long
block is not *necessarily* unexpected". A ping operation should not take
multiple seconds to process, but it may of course be that Avahi is busy
with other stuff. If the design of Avahi is such that periods of
unresponsiveness may happen during normal operation, then a long block
during pinging can be sort of expected.

> 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).

What bug has been open for 6 months? If you mean 58758, which has been
open for a bit less than 5 months, I seriously doubt that fixing
module-zeroconf-publish will get rid of the delays that the reporter is
seeing. Or more accurately, the delays that Matthew Cope is seeing
(there are several people commenting on the bug, but Matthew is the only
one who has provided logs).

-- 
Tanu

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.