In the current revision the EventSensor stuff is not event driven,  
well not that it was even, although I had an old change set that  
attempted that since on the
mac, with the carbon VM, events are async and the event semaphore is  
used, however that was obsoleted by changes last year.

Rather Morphic as part of it's 1/50 of a second processing looks for  
any events on the event queue, if not found it asks the VM for events  
off the VM event queue.
If EventSensor sees the event semaphore was fired then it notes the  
VM could be event semaphore driven.
EventSensor also has a tickler poll of 1/2 a second that pulls any  
pending events from the VM event queue so that cmd-'.' processing can  
occur if Morphic looses it's mind, so it's more of Morphic driving  
things, versus the EventSensor logic driving things.

The interesting thing is how events coming, get mucked with, then  
passed into Morphic which does lots of work with them and I suspect  
results in 90% of the cycles devoted to decoding what should happen,  
that process is much more interesting to follow for optimization issues.

On 13-Nov-05, at 9:09 PM, tim Rowledge wrote:

>
> On 13-Nov-05, at 2:30 PM, Bert Freudenberg wrote:
>
>>
>> Am 13.11.2005 um 21:40 schrieb Serge Stinckwich:
>>
>>> Hi all,
>>> i started to look at the Sensor stuff. I have two questions :
>>> - there is two classes : EventSensor and InputSensor. The first  
>>> one seems to be a replacement of the last one. Do we really need  
>>> two classes or could we try to merge both ?
>>
>> IMHO there's nothing wrong with having both classes. In a minimal  
>> image / VM the old polling InputSensor should actually still work.  
>> Which is good for getting new ports started. If the VM implements  
>> the event primitives, the EventSensor will take over.
>
> Sadly this isn't how it works any longer. If you look deep into the  
> code (which of course allows the code to look deep into you) you  
> will see that the 'old' input sensor code cannot get to run. Once  
> upon a time entering an MVC project would awaken a simple  
> InputSensor for example. I did make some suggestions for a cleaner  
> input handler a while ago but no one seemed to care enough to even  
> want to discuss it. There's a related email at http:// 
> lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/ 
> 073583.html
>
> There isn't really anything simpler about the old polling prims  
> than the newer  sort-of event prims so we don't really have any  
> good reason to keep them. I was planning on cutting them out  
> sometime soon along with lots of other extraneous junk.
>
>
> tim
> -- 
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>
>
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===