[Vm-dev] Re: [Pharo-project] Event history question

John M McIntosh johnmci at smalltalkconsulting.com
Thu Nov 20 18:26:44 UTC 2008


Ok, tthe TheInterruptSemaphore  is signalled in checkForInterrupts()  
via usage of setInterruptPending().

As far as I know the only place that it is used is by the VM host  
platform keyboard handling logic
only *IF* you are using an image that predates EventSensor (Aug 2000)

Now since most people use an image that has this class what happens is

(a) The process running EventSensor>>processEvent:   looks at the  
incoming VM generated keyboard event and
if it decides that the keys pressed meet it's criteria of what an  
interrupt is then it signals in the EventSensor interruptSemaphore
That then wakes up the interrupt watcher process

InputSensor>>userInterruptWatcher
running at Processor lowIOPriority.

This means of course the process that is running  
EventSensor>>processEvent:  has to be able to run.
You could simplify things here and fork off the userInterruptWatcher  
logic in EventSensor>>processEvent:
and as I think Michael noticed rip out the InterruptWatcherProcess and  
InterruptSemaphore

On 20-Nov-08, at 7:18 AM, Igor Stasenko wrote:

> 2008/11/20 Michael Rueger <m.rueger at acm.org>:
>> Igor Stasenko wrote:
>>
>>> If i remember correctly, an interrupt semaphore is used to awake a
>>> process which watching for interrupts.
>>> And indeed, when key combination matching an interrupt key code,
>>> it calls setInterruptPending(), which is then eventually leads to
>>> signaling a semaphore which registered as interrupt semaphore.
>>> You can't handle it on image side, because you may not have chance  
>>> to
>>> get to it (if there's another process running on same or higher
>>> priority than event ticker process).
>>> While in VM, regardless what image does, it periodically checks for
>>> interrupts, and during handling OS events, it checks if an interrupt
>>> key pressed, and if so, then signals the semaphore.
>>> At least, this is how it looks on Win32.
>>
>> The question really was if it is in the VM but rather if it (still)  
>> should
>> be in the VM.
>> After some discussions with John I'm pretty sure we can remove the  
>> interrupt
>> semaphore code from the VM. For now that would mean that the image  
>> code
>> still referring to it should/can be removed.
>>
>
> In this case, i'd like to read John's reasoning, why its safe to
> remove it from VM.
>> From my perspective , it should stay, because you can't imitate same
> behavior on language side safely.
>
>> Michael
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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





More information about the Vm-dev mailing list