[squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

David T. Lewis lewis at mail.msen.com
Thu Apr 14 02:46:55 UTC 2011


On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> > Understood, though my question was intended to be about the existing
> > primitiveMillisecondClock, which will presumably be retained for a
> > few more years. Andreas committed a fix for a rather nasty bug related
> > to a constant in the image being out of sync with a constant in the VM.
> > The method comment noted that "This should be primitive but it ain't"
> > so I was just offering to add the primitive and update Squeak trunk
> > to use it when available.
> 
> Why does the existing primitiveMillisecondClock have to be maintained?
> Is there a lot of code that depends on it rolling over? No sarcasm
> intended, it's an honest question.

It is used by Time class>>millisecondClockValue, so see senders of
#millisecondClockValue.

>From the point of view of the VM, the primitive needs to be maintained
because many existing images expect it to be there. From the point of
view of the image, a different and better implementation can easily
be adopted. My question was from the point of view of the VM, if we
assume that many images will expect primitiveMillisecondClock to be
there, should we also add primitiveMillisecondClockMask such that
those images can obtain the correct mask value if they choose to
do so (both the VM and the image changes are minor updates).

With respect to code that depends on the clock rollover, I expect
that the most serious concern would related to socket timeouts, which
might intermittently affect server applications, Seaside, etc.

To be clear, the patch that Andreas committed will fully address
the problem for all current VMs and images, so this discussion
has little or no practical impact. It's really just about tidying
up some loose ends just in case the the primitiveMillisecondClock
ends up getting used for a few years longer than any of us might
care to anticipate ;)

Dave




More information about the Squeak-dev mailing list