Newsgroups: comp.lang.smalltalk
Path: utzoo!utgpu!cunews!bnrgate!bqnes74!news
From: CWatts@BNR.CA (Carl Watts)
Subject: Re: Making MVC Controllers in Smalltalk-80 v2.5 not consume 100% of the Processor
Message-ID: <1991Jun6.154208.16270@bqnes74.bnr.ca>
Sender: news@bqnes74.bnr.ca
Organization: Bell Northern Research
Date: Thu, 6 Jun 91 15:42:08 GMT

Yen-Ping Shan <shan@cs.unc.edu> from the University of North Carolina, Chapel Hill sent me a mail message regarding the code I posted recently to make MVC not consume 100% of the Processor.  I think his comments and my reponse will be of general interest so I'm posting them here.

	"I've tried similar implementation before but discovered that the mechanism"
	"does not work for all cases.  For example, a universal right button menu"
	"would require special treatment.  It turned out that the effort to make"
	"the mechanism work for all cases is greater than implementing an"
	"event-driven MVC (please see my report in OOPSLA'89)."

	"If you are interested in the code I wrote, you can ftp it from"
	""ftp.cs.unc.edu".  It's under pub/MoDE."

Its true that my mechanism makes no attempt to make MVC consume the minimimum amount of the Processor possible.  I agree that to do this would be tantamount to rewriting MVC to be event-driven.  But that was not my goal.

My goal was to make MVC not consume 100% of the Processor MOST of the time.  This is the most important aspect.  If MVC tended to consume very little Processor when the user wasn't doing anything, and only consumed somewhat less than 100% (on average) when the user was doing something, then my goals were achieved.

As my implementation shows, this can be done with VERY LITTLE trouble.  And with very important benefits namely that Processes running at less than userSchedulingPriority WILL RUN (in the Processors spare time).  My implementation also has no problem with "a universal right button menu" (though I must admit, I'm not sure what the means).

I'm very interested in your implementation Shan and I will ftp it from your machine when I get back from Germany.

(Oh how I wish ParcPlace would productize a version of Smalltalk-80 v4.0 that didn't use the hosts windowing systems so people like us that find experimenting with the implementation of different windowing systems and display paradigms wouldn't be forced into the strictly-rectangular-overlapping-window-with-foreign-window-manager-like-X-windows mode.  I'm fiercely holding onto Smalltalk-80 2.5 just so I can do things like this...)

(Maybe someone should implement full backward compatibility of StandardSystemView and Display into Smalltalk-80 v4.0?  That way those people who want to write platform applications could have there platform windows and those who wanted to write Smalltalk applications and experiment with user-interface paradigms under a window/display system completely implemented in Smalltalk could also do that...   Hmmm...  Methinks I've got another project to add to my list...)
