Cache /etc/mdns.allow information in the process

[pemensik]

While writing a response to mdns or mdns_minimal question of Fedora devel list, I have realized nss-mdns is too naive when parsing /etc/mdns.allow configuration.

I think nss-dns plugin of glibc could be an inspiration for a well working basic caching of configuration. I think it does some smartness about /etc/resolv.conf parsing. We want to avoid unnecessary file reading on every query request, which current mdns? plugin variants does IMO. If we could cache missing file /etc/mdns.allow, we could use just single variant.

We could as well fetch list of domains to use from avahi-daemon itself and cache that. That way we could receive instructions how to handle IPv4 and IPv6 separately, which would allow to use just single mdns plugin instead of 6 separate plugins provided now.

[pemensik]

An example how nss_dns caches /etc/resolv.conf information might be at __resolv_conf_get_current function of glibc. Part of res_ninit() call used in -lresolv library.

It would be better if we could find simpler version than this.

[pbrezina]

Bump. Was there any progress?

[pemensik]

No, there is no obvious way to store information in thread safe way between multiple resolutions. I were told glibc stub uses something special in dns plugin, which we cannot copy into mdns plugin. I have started thinking about a new API with existing context. It would allow keeping some information between resolutions, inside single thread. But this is not the best place for expanding such ideas.

I do not think current getaddrinfo() call or related calls provide any decent place to store cached information. It might be good to ask about this on Fedora devel, whether it can be solved a good way with what we have now.

[arrowd]

No, there is no obvious way to store information in thread safe way between multiple resolutions.

Can you elaborate on this a bit, please? Can't we use thread-local variables for that, for instance?

[pemensik]

There is not function to free such information. It would be there forever. If we would use per-thread storage, it would have multiple copies without ability to free them at controlled time. If we had just static global variable, we would have to include locking into this, preventing race conditions when requested in multiple threads. Current way is not too efficient, but is thread safe.