[pulseaudio-discuss] Making module-zeroconf-publish non-blocking
Tanu Kaskinen
tanu.kaskinen at intel.com
Wed May 15 04:19:04 PDT 2013
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.
More information about the pulseaudio-discuss
mailing list