Hi John -

The reasoning sounds about right but you have to be *very* careful when 
making changes to that logic. As a simple example, fetchMoreEvents is 
not only called from the event tickler and consequently the interrupt 
handler might be forked at the priority of some random process using 
"Sensor anyButtonPressed" ;-) If I remember correctly, there were 
several other gotchas in this area (I tried changing some of this stuff 
in Croquet once) and since this is a place where screwing up will make a 
lot of people *very* unhappy I would advise extreme caution when making 
these changes.

Cheers,
   - Andreas

John M McIntosh wrote:
> 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
> ===========================================================================
> 
> 
> 
> 
>