(In reply to Patrick McManus [:mcmanus] from comment #22 <https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c22>)> ((In reply to bugzilla.mozilla.org from comment #21 <https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c21>) > > This whole thing is about getting TTL for in-Firefox caching, right? > > yes - each time we look at this we do need the cache because the the number > of names that are looked up in the browser (most of them speculatively) > tends to overwhelm the os cache. I'd be happy to look at data in a separate > bug to revisit, of course.
Can someone be more specific on what "overwhelm"s the os cache? I assume all the names still need to be looked up in te os and thus get in the os cache. Is it cache hits that are too many - that sounds unlikely. Or is it entries with very low ttl that you are caching longer in the browser to avoid lookups? -- Bob Harold hostmaster, UMnet, ITcom Information and Technology Services (ITS) rharo...@umich.edu 734-647-6524 desk On Sun, Mar 1, 2015 at 3:32 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Mark Andrews: > > > In message <87k2z0vksq....@mid.deneb.enyo.de>, Florian Weimer writes: > >> * Mark Andrews: > >> > >> > getaddrinfo was designed to extended. It wouldn't be hard to add ttl > >> > information to getaddrinfo, just add a ai_ttl to the structure at the > >> > end and define a flag to say whether it is valid. > >> > >> struct addrinfo cannot be extended in this way because its size is > >> part of the ABI, and callers are even encouraged to allocate struct > >> addrinfo objects to pass the hints. > > > > And that is something that can be dealt with by setting a flag bit > > when calling getaddrinfo. As I stated getaddrinfo is designed to be > > extended. > > This is doesn't work for an important case, which I mentioned in the > next paragraph: > > >> I've already found one Debian package which embeds a struct addrinfo > >> field in the middle of a struct defined in a header file (the shishi > >> Kerberos implementation). Unfortunately, changing struct addrinfo > >> in the way you propose has an extremely high risk of breaking > >> applications. > > We don't have the luxury of recompiling the entire world if we change > something in libc. We tried something similar with another > supposedly-extensible struct, and all hell broke lose as a result. > Changing the size of struct addrinfo simply not an option for us. > _______________________________________________ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs >
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
