On Wed, 2013-05-15 at 14:06 +0300, Tanu Kaskinen wrote: > On Wed, 2013-05-15 at 16:02 +0530, Arun Raghavan wrote: > > 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. Uh, I was ignoring the fact that Avahi isn't running in your tests. Is it auto-starting as a result of the ping from PulseAudio? If yes, I guess it's less surprising that the ping takes some time, if the Avahi startup is slow. If auto-starting is not used, then the D-Bus daemon should quickly send an error. > > However, > > I don't see the timeout take this long every time. I'm trying to find > > out why this is. -- 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.
