<div dir="ltr"><pre class="" id="comment_text_28">(In reply to Patrick McManus [:mcmanus] from <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c22">comment #22</a>)
<span class="">> ((In reply to <a href="http://bugzilla.mozilla.org">bugzilla.mozilla.org</a> from <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1093983#c21">comment #21</a>)
> > 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.</span>

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?</pre><pre class="" id="comment_text_28"><br></pre></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br>-- <br>Bob Harold<br>hostmaster, UMnet, ITcom<br>Information and Technology Services (ITS)<br><a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a><br>734-647-6524 desk<br></div></div>
<br><div class="gmail_quote">On Sun, Mar 1, 2015 at 3:32 PM, Florian Weimer <span dir="ltr"><<a href="mailto:fw@deneb.enyo.de" target="_blank">fw@deneb.enyo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Mark Andrews:<br>
<span class=""><br>
> In message <<a href="mailto:87k2z0vksq.fsf@mid.deneb.enyo.de">87k2z0vksq.fsf@mid.deneb.enyo.de</a>>, Florian Weimer writes:<br>
>> * Mark Andrews:<br>
>><br>
>> > getaddrinfo was designed to extended.  It wouldn't be hard to add ttl<br>
>> > information to getaddrinfo, just add a ai_ttl to the structure at the<br>
>> > end and define a flag to say whether it is valid.<br>
>><br>
>> struct addrinfo cannot be extended in this way because its size is<br>
>> part of the ABI, and callers are even encouraged to allocate struct<br>
>> addrinfo objects to pass the hints.<br>
><br>
> And that is something that can be dealt with by setting a flag bit<br>
> when calling getaddrinfo.  As I stated getaddrinfo is designed to be<br>
> extended.<br>
<br>
</span>This is doesn't work for an important case, which I mentioned in the<br>
next paragraph:<br>
<span class=""><br>
>> I've already found one Debian package which embeds a struct addrinfo<br>
>> field in the middle of a struct defined in a header file (the shishi<br>
>> Kerberos implementation).  Unfortunately, changing struct addrinfo<br>
>> in the way you propose has an extremely high risk of breaking<br>
>> applications.<br>
<br>
</span>We don't have the luxury of recompiling the entire world if we change<br>
something in libc.  We tried something similar with another<br>
supposedly-extensible struct, and all hell broke lose as a result.<br>
Changing the size of struct addrinfo simply not an option for us.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-jobs</a> mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
</div></div></blockquote></div><br></div>