On Thu, Sep 13, 2012 at 3:03 PM, Mads Kiilerich <span dir="ltr"><<a href="mailto:mads@kiilerich.com" target="_blank">mads@kiilerich.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":xz">This commando pattern on the openers internal audit flag seems a bit like an unfortunate hack.</div></blockquote><div><br></div><div>The prior two patches pretty clearly make mustaudit a public field.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":xz">Wouldn't it be cleaner to add a 'dontaudit' flag to sopener() or create a new opener without audit?<div class="yj6qo ajU">
<div id=":vu" class="ajR" tabindex="0"></div></div></div></blockquote></div><br><div>No.</div><div><ul><li>Adding a dontaudit flag to __init__ doesn't work because at the time of construction, we don't know what the intended use of the opener will be, and while we can always avoid auditing reads, we must audit writes.</li>
<li>My original unpublished version of this patch *did* create a new opener, but that was even more janky: it had to figure out what the current opener type was, then create either one or two openers depending on whether the existing opener was an fncacheopener or a normal opener.</li>
</ul></div><div>IOW, I don't think there's a cleaner way to do this.</div><div><br></div>