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
