<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><style>@font-face {
        font-family: Calibri;
}
@font-face {
        font-family: Verdana;
}
@font-face {
        font-family: Webdings;
}
@font-face {
        font-family: Arial Narrow;
}
@page WordSection1 {margin: 72.0pt 72.0pt 72.0pt 72.0pt; }
P.MsoNormal {
        MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New 
Roman","serif"; FONT-SIZE: 12pt
}
LI.MsoNormal {
        MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New 
Roman","serif"; FONT-SIZE: 12pt
}
DIV.MsoNormal {
        MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New 
Roman","serif"; FONT-SIZE: 12pt
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.apple-style-span {
        
}
SPAN.EmailStyle18 {
        FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d
}
.MsoChpDefault {
        
}
DIV.WordSection1 {
        
}
</style>

<style id="owaParaStyle">P {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body lang="EN-NZ" link="blue" vlink="purple" ocsi="0" fPStyle="1">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div><span style="COLOR: #548dd4">Kevin Brintnall addressed the proletariat thusly:</span></div>
<div>
<div class="WordSection1">
<p class="MsoNormal"><span style="COLOR: #548dd4">&gt;I noticed that r2130 adds a call to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_parsetime</span><span style="COLOR: #548dd4"> to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_daemon.c</span><span style="COLOR: #548dd4">. &nbsp;I think this is problematic since </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_parsetime</span><span style="COLOR: #548dd4"> is not thread-safe. It would probably make more sense to do the calculations in the client and pass the absolute </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">time_t</span><span style="COLOR: #548dd4"> to the daemon. &nbsp;That's what we've done with UPDATE. &nbsp;We already rely on time synchronization between client&#43;server so I don't see that as a real issue.</span></p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">I hadn’t realised that rrd_parsetime wasn’t threadsafe.&nbsp; The easiest thing here is probably to change it to just take a time_t as the parameter; the rrd_client already passes a pre-parsed time_t anyway, so there’s no need to reparse it here.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="COLOR: #548dd4">&gt;Also, </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_set_no_overwrite()</span><span style="COLOR: #548dd4"> is not thread-safe.. &nbsp;This is a big problem for the daemon. &nbsp;It writes a global (un-guarded) variable. &nbsp;There are unavoidable race conditions here. &nbsp;I think a better approach would be either:</span></p>
<p class="MsoNormal"><span style="COLOR: #548dd4">&nbsp;- add an argument to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_r()</span><span style="COLOR: #548dd4">, passing it through to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_fn()</span><span style="COLOR: #548dd4"></span></p>
<p class="MsoNormal"><span style="COLOR: #548dd4">&nbsp;-&nbsp;&nbsp;create a new API function that takes a boolean for whether create should clobber an existing file.... &nbsp;then, re-implement </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_r()</span><span style="COLOR: #548dd4"> in terms of that function (with today's default)... &nbsp;stil passing the arg through to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_fn()</span><span style="COLOR: #548dd4">.</span></p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">I created rrd_create_set_no_overwrite in order to get around having to modify the rrd_create function; the opt_no_overwrite variable is a pain in the neck and shouldn’t really exist.&nbsp; I agree that we should add an argument to rrd_create_r, however this would change the API (the rrd_create_r is a documented function in the library?).&nbsp; Maybe rename rrd_create_r as rrd_create_r2, add the parameter, and create an rrd_create_r that defaults the opt_no_overwrite… This is really a separate issue to the changes, but was not really a problem until rrd_create_r became added to the daemon.&nbsp; So, rrd_create_r was not actually thread-safe yet due to this opt_no_overwrite variable.&nbsp; This also means adding the parameter to rrd_create_fn although I think this is not a big issue.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="COLOR: #548dd4">&gt;Also, in </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">handle_request_create()</span><span style="COLOR: #548dd4">, maybe it would make sense to do the validation (i.e. step and last_up) in </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_r()</span><span style="COLOR: #548dd4"> and rely on the return value from </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_create_r()</span><span style="COLOR: #548dd4"> to detect whether there was a failure? &nbsp;That way, the validation code stays in the same place.</span></p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">The validation is normally done in rrd_create and so this is bypassed by a call to rrd_create_r; since it was two small checks I didn’t think it worth the effort of moving the tests from rrd_create to rrd_create_r (and again, I was trying to avoid modifying the rrd_create_r function).&nbsp; I think this can probably stay?</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="COLOR: #548dd4">&gt;Also, on </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">rrd_daemon.c</span><span style="COLOR: #548dd4"> lines 1830..1831, it looks like it could be re-written more nicely as:</span></p>
<p class="MsoNormal"><span class="apple-style-span"><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4; FONT-SIZE: 8.5pt">- status = buffer_get_field(&amp;buffer, &amp;buffer_size, &amp;tok );</span></span><span style="COLOR: #548dd4"></span></p>
<p class="MsoNormal"><span class="apple-style-span"><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4; FONT-SIZE: 8.5pt">- for(;(tok &amp;&amp; !status);status = buffer_get_field(&amp;buffer, &amp;buffer_size, &amp;tok ))&nbsp;{</span></span><span style="COLOR: #548dd4"></span></p>
<p class="MsoNormal"><span class="apple-style-span"><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4; FONT-SIZE: 8.5pt">&#43; while ((status =&nbsp;buffer_get_field(&amp;buffer, &amp;buffer_size, &amp;tok) == 0 &amp;&amp; tok) {</span></span><span style="COLOR: #548dd4"></span></p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">This is just a legacy of how this code evolved.&nbsp; I’m happy to change this or not (you want another close bracket before the == though I think)</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="COLOR: #548dd4">In rrd_last.c, we seem to have lost a call to </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">free(opt_daemon)</span><span style="COLOR: #548dd4">. &nbsp;Is that intentional?</span></p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Can you be more specific?&nbsp; I’m not sure where you’re referring to.&nbsp; The free() is still called in the argument processing; none of the other functions free the opt_daemon after handling either since it is potentially used later.</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="COLOR: #548dd4">In&nbsp;</span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">handle_request_last()</span><span class="apple-style-span"><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4; FONT-SIZE: 8.5pt">, </span></span><span style="COLOR: #548dd4">it seems we could get the last update time without a flush by using </span><span style="FONT-FAMILY: 'Courier New'; COLOR: #548dd4">cache_item_t.last_update_stamp</span><span style="COLOR: #548dd4"> and adjusting down to the nearest RRD step size? &nbsp;Then, no flush is required and the existing behavior is preserved.</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span>&nbsp;</p>
<p class="MsoNormal">Probably…&nbsp; However I’m not familiar with the cache data structures and thought it best to avoid this, particularly since the previous behaviour did a flush anyway.&nbsp; Also, by making the flush an optional parameter (in the client) it means you can retrieve both the last cache update time and also the last flush time.&nbsp; So, the call from rrd_client will preserve the existing behaviour (return last data update) as it forces a flush.&nbsp; </p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">If we can get the last time accurately via the cache data structures then this would be preferable (although the rrd_info would still need a flush as it gets a whole stack more data as well) – can you let me know the code required to obtain it?</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal">Steve</p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span>&nbsp;</p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt"></span>&nbsp;</p>
<div style="TEXT-ALIGN: center" class="MsoNormal" align="center"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt" lang="EN-US">
<hr align="center" size="2" width="100%">
</span></div>
<p class="MsoNormal"><b><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Steve Shipway</span></b></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 10pt">ITS Unix Services Design Lead</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 10pt">University of Auckland, New Zealand</span></p>
<p class="MsoNormal"><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 10pt">Floor 1, 58 Symonds Street, Auckland</span></p>
<p class="MsoNormal"><i><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #595959; FONT-SIZE: 10pt">Phone: &#43;64 (0)9 3737599 ext 86487</span></i></p>
<p class="MsoNormal"><i><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #595959; FONT-SIZE: 10pt">DDI: &#43;64 (0)9 924 6487</span></i></p>
<p class="MsoNormal"><i><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #595959; FONT-SIZE: 10pt">Mobile: &#43;64 (0)21 753 189</span></i></p>
<p class="MsoNormal"><i><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #595959; FONT-SIZE: 10pt">Email: <a href="mailto:s.shipway@auckland.ac.nz" target="_blank"><span style="COLOR: #595959">s.shipway@auckland.ac.nz</span></a></span></i></p>
<p class="MsoNormal"><span style="FONT-FAMILY: Webdings; COLOR: green; FONT-SIZE: 18pt" lang="EN-GB">P</span><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: blue; FONT-SIZE: 11pt" lang="EN-GB"> </span><span style="FONT-FAMILY: 'Arial Narrow','sans-serif'; COLOR: green; FONT-SIZE: 10pt" lang="EN-GB">Please consider the environment before printing this e-mail</span><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: blue; FONT-SIZE: 11pt" lang="EN-GB"> </span><span style="FONT-FAMILY: 'Verdana','sans-serif'; COLOR: navy; FONT-SIZE: 7.5pt" lang="EN-GB"></span></p>
<p class="MsoNormal"><i><span style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 10pt"></span></i>&nbsp;</p>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; PADDING-BOTTOM: 0cm; PADDING-LEFT: 4pt; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; BORDER-RIGHT: medium none; PADDING-TOP: 0cm">
<div>
<div>
<p style="MARGIN-BOTTOM: 12pt" class="MsoNormal">&nbsp;</p></div></div></div></div></div></div></body></html>