Polling

Lex Spoon lex at cc.gatech.edu
Sat Feb 26 01:42:06 UTC 2000


Paul Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> agree at carltonfields.com wrote:
> > I'd be obliged if someone would explain why polling is a fatal flaw? 
> 
> * Polling uses up CPU cycles needlessly.
> * To avoid using up those CPU cycles, one puts in delays.
> * Delays make GUIs less responsive.
> * Event quesues can be prioritized, which allows more sophisticated apps
> * The OS is probably supplying events anyway -- so converting them to a
> virtual mosue is another wasteful layer of extra works.
> * Polling clutters up the logic of the widgets
> * Polling makes it harder to stuff events into a system for automated
> testing.
> 

In theory, these are all correct.  But in the specific case of Squeak
polling for mouse events, they actually don't cause problems.  In turn:

	1. My system runs at 0.0% CPU if Squeak is idle, even in Morphic.  So
it's using less than a tenth of a percent to do the polling.

	2. The delays are only 10 milliseconds long, which is faster than most
monitors can even refresh.  Thus the delays do not make the system any
less responsive.

	3. Regarding event queues, first, they can be done whether you poll the
events or not, and second, mouse events are rare from a CPU's
perspective.  There is almost always just one event waiting, so there's
no need to get fancy with it.

	4. The widgets can't tell you are polling, at least in Morphic, because
everything is based on events internally.  Thus widgit logic is
unaffected.

	5. For testing, you can generate synthetic MorphicEvent's just fine.


That said, there *are* some weaknesses due to polling--people aren't
going on about a *complete* nothing.  The weaknesses are:

	1. Sometimes a mouse click gets lost.

	2. Mouse clicks don't always happen in the correct place, if you are
moving the mouse quickly.


These weaknesses don't seem all that bad, to me.  Annoying, yes, but
they certainly don't ruin Morphic.


> 
> >  I can understand why avoiding the event loop is a good thing, 
> > and await seeing it truly done well.

I posted an implementation that I think was pretty reasonable.  But the
problem simply hasn't bubbled up on SC's priority list.  Frankly, this
doesn't bother me; there are bigger fish to fry.




> 
> > Wasn't the preceding paragraph a highly overreaching overstatement of affairs, or should I really dump Squeak and go back to hacking Python?
> 
> Python's cool. Zope's cool. TK's cool. Squeak should learn from them.

Morphic is pretty cool, too.  Other systems could learn something from
Squeak, as well.


I think what everyone *really* wants are simply more traditional
widgits.  No need to try and blame this on the framework itself.


Lex





More information about the Squeak-dev mailing list