[avahi] Why are callbacks called already during registration?

Lennart Poettering lennart at poettering.de
Mon Nov 14 18:42:23 PST 2005

On Sun, 13.11.05 18:38, Aaron Isotton (aaron at isotton.com) wrote:

> Hi,
> Is there some reason why the callbacks (at least foravahi_client_new and
> avahi_entry_group_new) are called already during the function call?

Humm. Yes, there is some reason. AvahiEntryGroup and AvahiClient
maintain a state variable. The callback functions are called the first
time when the state is initialized, i.e. *inside* the _new()

In contrast: Avahi*Browser and Avahi*Resolver objects do not maintain
a state variable, instead event callbacks are called when asynchronous
events happen. That is always *after* the initialization of the

When should the state change callback functions be called the first
time in your opinion? In the "next" main loop iteration? This would be
even more annoying than the current situation, because apps which
don't make use of a main loop or which want to start the first
operations before entering the main loop, would access objects that
are not in any official state yet. 

Firing the state change events from inside the main loop would have
the ugly side effect that the get_state() functions might get
out-of-sync with the state tracked with  the state change callbacks. 

> This makes wrapping avahi in C++ a HUGE pain.

I acknowledge that this is hard to deal with sometimes. In fact, I
stumbled over that behaviour myself more than once. But actually I was
unable to find a solution that was any better in my eyes.

> Would it be feasible/reasonable to call the callbacks only later when
> the poller is iterated?

I don't think so. I haven't been able to find a cleaner solution for
this issue yet. You're welcome to suggest one, I would certainly
consider implementing it. However - it must be a real improvement about
the current situation.

I don't know if it helps you much, but anyway: the initial state of
AvahiClient and AvahiEntryGroup is completely static, and only changed
once in the _new() functions. Therefore you might simply choose to
ignore that event and dispatch it manually just after calling the
_new() function, like this:

client = avahi_client_new(poll_api, 0, callback, NULL, &error);
callback(client, avahi_client_get_state(client), NULL);

Snorp, I wonder how did you handle this issue in the Mono bindings?

Aaron, are you interested in maintaining your C++ wrappers in our
upstream SVN? How complete are they? How complete do you plan them to


Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/

More information about the avahi mailing list