<br><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
On 14.04.2011, at 04:46, David T. Lewis wrote:<br>
<br>
&gt;<br>
&gt; On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:<br>
&gt;&gt; On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis &lt;<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; Understood, though my question was intended to be about the existing<br>
&gt;&gt;&gt; primitiveMillisecondClock, which will presumably be retained for a<br>
&gt;&gt;&gt; few more years. Andreas committed a fix for a rather nasty bug related<br>
&gt;&gt;&gt; to a constant in the image being out of sync with a constant in the VM.<br>
&gt;&gt;&gt; The method comment noted that &quot;This should be primitive but it ain&#39;t&quot;<br>
&gt;&gt;&gt; so I was just offering to add the primitive and update Squeak trunk<br>
&gt;&gt;&gt; to use it when available.<br>
&gt;&gt;<br>
&gt;&gt; Why does the existing primitiveMillisecondClock have to be maintained?<br>
&gt;&gt; Is there a lot of code that depends on it rolling over? No sarcasm<br>
&gt;&gt; intended, it&#39;s an honest question.<br>
&gt;<br>
&gt; It is used by Time class&gt;&gt;millisecondClockValue, so see senders of<br>
&gt; #millisecondClockValue.<br>
&gt;<br>
&gt;&gt; From the point of view of the VM, the primitive needs to be maintained<br>
&gt; because many existing images expect it to be there. From the point of<br>
&gt; view of the image, a different and better implementation can easily<br>
&gt; be adopted. My question was from the point of view of the VM, if we<br>
&gt; assume that many images will expect primitiveMillisecondClock to be<br>
&gt; there, should we also add primitiveMillisecondClockMask such that<br>
&gt; those images can obtain the correct mask value if they choose to<br>
&gt; do so (both the VM and the image changes are minor updates).<br>
&gt;<br>
&gt; With respect to code that depends on the clock rollover, I expect<br>
&gt; that the most serious concern would related to socket timeouts, which<br>
&gt; might intermittently affect server applications, Seaside, etc.<br>
&gt;<br>
&gt; To be clear, the patch that Andreas committed will fully address<br>
&gt; the problem for all current VMs and images, so this discussion<br>
&gt; has little or no practical impact. It&#39;s really just about tidying<br>
&gt; up some loose ends just in case the the primitiveMillisecondClock<br>
&gt; ends up getting used for a few years longer than any of us might<br>
&gt; care to anticipate ;)<br>
&gt;<br>
&gt; Dave<br>
<br>
</div></div>I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what&#39;s the point of changing the old one now?<br>

<br>
I&#39;d still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?<br>
</blockquote><div><br></div><div>I&#39;ve heard this argument advanced (that the old interface is cheaper because of no large integers) but I think it&#39;s largely a straw man.  If you consider the simplicities that accrue from using a 64-bit clock that can&#39;t wrap and is synchronised to wall time (i.e. that Time now is derived from those same microseconds) then it&#39;s reasonable to assume the large int allocation cost will be substantially if not entirely recouped by simplicities higher up in Time, Delay et al.  No, I don&#39;t have figures; only experience with VW where we didn&#39;t notice any degradation but did loose a number of painful 45 1/2 day bugs.</div>
<div><br></div><div>2˘</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Bert -<br>
<br>
<br>
</font></blockquote></div><br>