Berserk idleLoop in event handling?

Andreas Raab andreas.raab at gmx.de
Thu Jan 8 23:00:35 UTC 2004


> if the idle loop doesn't get to run much
> then the event polling is pretty rare. This might become a problem in
> some situations I suppose.

No. If you poll for events when asked for new ones (via ioGetNextEvent or
the state based primitive set) the idle loop really is only ensuring we
respond in a more timely manner.

If that weren't the case, then setting the higherPerformance preference
would make Morphic totally unresponsive (since idleLoop is essentially never
being run as you can see in the ProcessBrowser - 100% CPU in the UI process
doing nothing).

Trust me, this stuff works. It is more complex than it strictly needs to be
(as I explained in various previous messages the event sensor's ioProcess
isn't needed since the VMs all do internal buffering) but it certainly
works.

Cheers,
  - Andreas

----- Original Message ----- 
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, January 08, 2004 7:08 AM
Subject: Re: Berserk idleLoop in event handling?


> Well, I've found out a little more about my particular problems on the
> ol'Acorn. Not too long ago I 'fixed' my implementation of the
> ioRelinquishProcessorForMicroseconds routine used in the prim for the
> idle loop. Note that this is for an OS that is cooperative
> multi-taksing like Mac OS9 etc, so there is no IO thread in the vm.
>
> The previous version took the number of microseconds specified to
> 'sleep' and shifted it by 14 for a rough conversion to centi-seconds -
> the granularity of pausing on the Acorn. Since the only user of the
> routine always passed on 1000, we always got 0 as an answer and the
> routine devolved to an ordinary event poll call. My fix was to say
> "hey, this should at least sleep a little" so I made sure the time was
> always at least one  centi-second. This made for a large part of the
> sluggishness; since the idleloop is running a lot of the time, the
> sleep time was a lot of the overall time. Effectivly this is a busy
> wait polling call on this OS; if the idle loop doesn't get to run much
> then the event polling is pretty rare. This might become a problem in
> some situations I suppose.
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Backup not found!  A)bort, R)etry or P)anic?
>




More information about the Squeak-dev mailing list