On Thu, 14 Feb 2002, Karl Goiser wrote:

> Hi People,
>
> Excuse me for butting in on this discussion, but I must admit that I
> fail to understand why Squeak needs to call gettimeofday() on any
> regular basis at all!

'primitiveResponse' dispatches out to a subset of primitives in the VM. as
the VM doesn't know how long they *may* take, it checks the clock before
and after the primitive to see if it took 'too long' and it should raise a
timer tick for soft-realtime operations.

As there are about 40k such primitives invoked/second, squeak does a *lot*
of gettimeofday.

ar's fix is to not do all that work for primitives we *know* can't take
that long. Another complimentary fix is to use an alternative tricks that
let us detect if a primitive took too long without having to do a full
gettimeofday each iteration. (threads, SIGALARM)

>
> Please excuse me if this is a dumb thing to say that displays a total
> lack of understanding of Squeak.  But I won't let that put me off.
> :-)  I'll continue:

See primitiveResponse.

>
> Aren't most modern operating systems and environments event driven?
> Shouldn't Squeak be doing nothing most of the time?
>
> If the problem is based on locating the mouse in the display, what
> happens with non-mouse systems like PDA's?  Anyway, don't mice only
> produce events on movement in most operating systems?
>
> It seems to me that there must be some serious design flaw somewhere
> (however see admittance of failure of understanding above).
>

Yaw, squeak seems to have busywait loops all over the place, but those
aren't the cause if this particular problem. Now, if you'd be interested
in quashing out some/many of those busywait loops.. :)

Scott