> From: "Eric Arseneau" <eat at huv.com>

[squeak being very active, polling etc.]

> As an example, the Palm platform pushes this idea to an extreme in  
order to
> increase the lifetime of batteries significantly.  When the system is 
> polling the pen location on the touch sensitive screen, the engineers 
> realized that the speed of people moving the stylus and the  
resolution of
> the touch screen did not require the polling loop to be running all the 
> time.  So, the poll loop actually puts the CPU and other  
components asleep
> for a small unit of time and then wakes up to see if any change  
gas occured.
> This seems like a very small thing, but they found that this gave  
percentage
> point improvements on battery consumption.  I believe the Squeak  
mentality
> needs to start to change to go in this direction in order to be more 
> effective on battery driven platforms.

Well, my take on this is that mainline Squeak should become  
completely passive.  There should be an entry point that has an event  
(or message) as an argument, processes that and then returns control  
to the host.

If time-based behaviour is desired, these should be scheduled  
externally, so that events come into the system at regular intervals.  


If there is no host system, an adapter can easily be placed on top  
of the basic passive system to 'activate' it and take the role of the  
event-supplier (either VM-based or image-based).

Why such a radical change?

Mainly for architectural reasons.  First, adding 'activity' to a  
passive system is easy, just place an event-loop on top of it.  On  
the other hand, adding passive event-reception to a fundamentally  
active system is much more difficult, because you have conflicting  
assumptions about ownership of the thread of control.  These can only  
be resolved by leaving each of the parties with its own  
thread-of-control, meaning multi-threading and the resulting  
synchronization, or by bizarre and fragile code-intertwining.

Morphic already has much of the basis for this, but because it is  
implemented on an active substrate, the architectural assumption of  
active-ness pervades the code, at least that's what it seems like to  
me.  Making the substrate inherently passive would flush out these  
architectural assumptions, which are often implicit and can go  
unnoticed for quite some time.

Marcel