[pulseaudio-discuss] [PATCH 3/3] zeroconf: Make Avahi usage in m-z-publish async

[Arun Raghavan]

On Wed, 2013-05-15 at 08:41 +0200, David Henningsson wrote:
> On 05/15/2013 06:43 AM, Arun Raghavan wrote:
> > This pushes all avahi-client code to a threaded mainloop from the PA
> > mainloop context. We need to do this because avahi-client makes blocking
> > D-Bus calls, and we don't want to block the mainloop for that long.
> 
> Thanks for working on this, but I wonder whether there is actually a use 
> case for having it blocking too?
> 
> E g, if you want a login sound and you want it played on the avahi 
> discovered sink instead of the local one, that will now be impossible, 
> because that sink is not discovered yet.

This is module-zeroconf-publish, so this should not be a problem. I
haven't fixed module-zeroconf-discover, because it's not loaded by
default and I want to keep the number of changes going in now minimal.
Plus, you've provided another potential reason. :)

> Also, is there a recent Avahi change that would cause this regression or 
> has it always been there? I've never heard of this 20 s delay before.

The 20s delay is really weird, I'll ask around to see why it might
happen. AFAIK, the default D-Bus timeout is 5s, and I do see in PA
startup (I don't have avahi-daemon starting at boot, maybe that's
another difference in our configs?).

FWIW, I'm doing some more testing with these patches. I can see GNOME
startup being faster by several seconds (between login and gnome-shell
coming up). I'm trying to make a more accurate measurement of this,
though.

> > The only exception to this now that I don't see a workaround for is
> > during module unload time. However, this shouldn't be a huge problem
> > since in most cases, this will only happen at server shutdown time.
> >
> > The bulk of the change is partitioning the data so that PA core objects
> > only (well, moslty) get accessed in the PA mainloop and Avahi calls
> 
> s/moslty/mostly

Thanks, fixed this.

-- Arun