"Peter Schuller" <peter.schuller at infidyne.com> wrote:> 
> Similarly, the IRC implementation is a polling one (you have to invoke
> processIO repeatedly, instead of the I/O running in as eparate thread).
> As a result, I'll probably write an alternative implementation for personal
> use.
> 

In this case, it's a deliberate design issue.  It's certainly open for
debate, but let me explain the reasoning.

First, using a blocking interface means adding a thread, and adding a
thread add a lot of complexity.  This includes design work (where do the
locks go?), complexity (implementing and using the locks), and added
difficulty in testing  (let's run this code a million more times and try
to make the bug appear again).  IMNSHO, many programmers severely
underistemate what they are getting into with threads.  To contrast, the
added complexity for polling is something like "how does my polling
routine get invoked"; once that is worked out, the focus is on the
function of the system.

Second, there are cases where polling doesn't have the ills that are
usually ascribed to it.  In particular, polling works well when failed
polls are cheap, and where polls can happen infrequently.  If a problem
meets both of these criterea, then polling will work fine.  CPU usage
will not be abnormally high, and responsiveness will be good.  IRC meets
both criteria, while HTTP serving probably does not. 



> And finally, there is the GUI which isn't entirly event driven (eg, moving
> a window consumes 100% CPU

In Morphic, dragging a large window easily uses up all of my 366 MHz
CPU, and it could easily use up 3-5 times more, as well.  It's not
wasted CPU in this case -- there are a lot of bits being shoved around!

In MVC, or with "fastDrag", well, the CPU is wasted.  See below.



; and in MVC (but not in morphic), pop-up menu
> navigation also consumes 100% CPU;

That's a deep design point in MVC: the currently active controller polls
the mouse and keyboard.  This dates back to machines where Smalltalk was
the OS, or at least the shell, of single-user ("personal") computers. 
Morphic makes more sense for Unixy systems where there might be multiple
users, and where CPU should be shared.

Incidentally, I went on a CPU-squashing hunt in MVC a while back, and
those squashes are in Squeak nowadays.  I didn't try to squash all the
instances, but instead only worried about cases where the user is idle. 
The idea was, the important case is when the user really is idle.  If a
user is busily clicking around, then using 100% CPU doesn't seem like a
very big deal.  Furthermore, there are simply a *lot* of polling loops
for various kinds of interactive code in MVC.  Fixing them would mean
adding a lot of code, and I'm not sure it would be worth it.

Morphic is a different story.  In Morphic, the system can simply limit
it self to 50-100 frames per second (whatveer you set it at).  If the
framerate excedes this, Morphic slows down.  It only requires a little
extra code in the main Morphic loop, and it's all finished.  This
difference in MVC versus Morphic is a classic case of having the right
abstractions for a job being explicit in the code.


-Lex