Smalltalk › Squeak › Squeak VM

Re: [squeak-dev] Time>>eventMillisecondClock and event timestamps

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Eliot Miranda-2

Re: [squeak-dev] Time>>eventMillisecondClock and event timestamps

Here's the VM event template:

typedef struct sqInputEvent

{

sqIntptr_t type; /* type of event; either one of EventTypeXXX */

usqIntptr_t timeStamp; /* time stamp */

/* the interpretation of the following fields depend on the type of the event */

sqIntptr_t unused1;

sqIntptr_t unused2;

sqIntptr_t unused3;

sqIntptr_t unused4;

sqIntptr_t unused5;

sqIntptr_t windowIndex; /* SmallInteger used in image to identify a host window structure */

} sqInputEvent;

The interesting thing here is that the timeStamp is already a 64-bit quantity on 64-bit platforms. So it is trivial to use UTC microseconds divided by 1000, or (UTC microseconds minus start microseconds) divided by 1000, to timestamp events on 64-bit platforms.

On 32-bit platforms we could either add an extra field at the end, or do something heinous with type. We could use 8 bits for the type and the top 24 bits to extend the 32-bit timestamp to 56 bits, which gives us 2.28 million years of milliseconds, or 2.28 thousand years of microseconds, while still leaving us 248 new event types (we use 8 at the moment).

So why don't we

- modify the VM to stamp events with the utc second clock, either using the full 64-bits of the timestamp on 64-bit platforms, or the 32-bit timestamp and the top 24 bits of the type field on 32-bit platforms.

- add a flag to the image flags that says whether events are time stamped in utc microseconds (if set) or in wrapping milliseconds from startup (or whatever the cross-platform backward-compatiblity semantics should be)

- modify primitive 94 primitiveGetNextEvent to examine the flag and either pass the event up as is, or convert it into a backards=compatible event depending on the flag copied from the image header at startup?

The benefit is that we can ditch support for millisecond time stamps in all parts of the VM other than in primitive 94 primitiveGetNextEvent.

On Tue, Sep 15, 2020 at 9:04 AM Eliot Miranda <[hidden email]> wrote:

Hi Marcel, Hi Dave,

On Sep 15, 2020, at 8:28 AM, Marcel Taeumel <[hidden email]> wrote:

Hi Dave.

> ... but I think that we should first look at how we might handle this better in the image ...

To some extent, this will be the good'ol discussion about how to achieve cross-platform compatibility. Whose job is it? VM? Image? Both? Do we want to have "platformName = 'Win32'" (or similar) checks in the image? Or can we rely on platform-independent information coming from the VM?

Well, thinking about maybe the future role of FFI for Squeak, we may not want to change too much in the VM at this point. A minimal-effort approach with in-image change might be the right thing to do. :-)

Agreed. My concerns are

1. The wrapping millisecond clock is a baaaaaad idea. It wraps in 49 days. The code that used to exist in Time was extremely complex and hard to maintain (fooling the system into being close to wrap around is not easy). And now we do have applications which are expected to run for long periods. But even though it is a bad idea we presumably have applications in images (someone mentioned RFB) which depend on the vm stamping events using the wrapping millisecond clock, and if possible the vm should continue to do so

2. we have a much better much simpler clock that does not wrap and can be used to compare times between images across the globe, the utc microsecond clock. If we want timestamps we should derive them from this clock

3. backwards compatibility. If we change event timestamps do we lose the ability to run 5.x images on the new vm? Is there a way that the vm can be informed by the image whether it wants timestamps? (We can add another image header flag to control the vm response)

Regarding 3. I can imagine adding a 32-bit field at the end of a vm event and have having 64 bits (existing time stamp plus new field) to allow stamping the event with the utc clock (& not utc now but the utc updated by the vm heartbeat at 500Hz).

Best,
Marcel

Am 15.09.2020 17:04:18 schrieb David T. Lewis <[hidden email]>:
I do not have any specific solution or approach in mind, but I think
that we should first look at how we might handle this better in the
image. The Windows VM is not doing anything wrong, on the contrary I
think that its policy of using native MSG timestamps feels like the
right thing to do.

It seems to me that the problem is our assumption that event timestamps
should match the millisecond clock in the VM. Certainly that can
be made to work, but seems to me like fixing the wrong problem.

Time class>>eventMillisecondClock is a recent addition. Maybe we
can find another way to synthesize event time stamps in the image.

Dave

On Tue, Sep 15, 2020 at 04:32:59PM +0200, Marcel Taeumel wrote:

> Hi all.
>
> Here is a quick thought: It should be possible to synthesize events from within the image to then use those synthesized events along with regular events. Think about testing, mouse over etc. Thus, either #eventMillisecondClock should be platform-specific, or all event timestamps that come from the VM should be similar ... which means that the Windows VM code needs to be changed to not use the MSG structure but ioMSecs.
>
> Best,
> Marcel
> Am 12.09.2020 21:58:50 schrieb David T. Lewis :
> Thanks Tim,
>
> I've been digging through version control history, and I think what
> I see is that the assumption of prim 94 matching prim 135 was valid
> through the life of the interpreter VM (squeakvm.org SVN sources) but
> that it had changed for Windows as of the public release of Cog.
>
> I don't see anything wrong with the Windows VM implementation (aside
> from the one bug that Christoph fixed), instead I think we may just
> be dealing with a holdover assumption that is no longer valid.
>
> I'm inclined to think we should see if we can make the prim 135
> dependence go away in the image. Some other way of synthesizing event
> time stamps maybe?
>
> Dave
>
> On Fri, Sep 11, 2020 at 03:45:35PM -0700, tim Rowledge wrote:
> > I think the key thing is that the answers from the primitive 135 must be aligned with the tick values obtained from primitive 94.
> >
> > Of course if prim 94 is properly functional (all elements of the event array are correctly filled in) then prim 135 should never be needed; it was created for those machines that waaaaay back when I added the input events still couldn't provide such data. I'm not entirely sure there actually were any....
> >
> > The only usage of prim 135 not related directly to events seems to be SmalltalkImage>>#vmStatisticsReportOn:, though there are several methods that looks a bit iffy.
> >
> > EventSensor>>#createMouseEvent is only used in a couple of places to do with rectangle transforming interactively, and probably ought to be improved.
> > EventSensor>>#nextEventSynthesized is only used if the EventSensor has no event queue and that is ... a bit complex but probably should never happen since we removed the old InputSensor years and years ago.
> > EventSensor>>#primGetNextEvent: - since we declare the prim essential maybe we should drop the fake-it code and really insist on the prim being there?
> > MorphicEvent>>#timeStamp looks like a probably redundant backup?
> > MouseEvent>>#asMouseMove looks like the new MouseMoveEvent ought to copy the time stamp from the receiver?
> >
> >
> >
> > tim
> > --
> > tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> > There are no stupid questions. But, there are a lot of inquisitive idiots.
> >
> >
> >
>

>

_,,,^..^,,,_

best, Eliot