Re: [Pharo-project] Event history question

> 2008/11/20 Michael Rueger <[hidden email]>:
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>:
>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>

>
> 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
>

>
> Igor Stasenko wrote:
>>
>> This also makes 1 less process hanging around, because there is no
>> need in setting up the userInterruptWatcher and semaphore for it
>> once you can do it from event ticker like following:
>>
>> (self isInterruptEvent: event) ifTrue: [
>>   interruptHandler isAlreadyRunning ifFalse: [  [self
>> handleInterrupt] forkAt: Processor severePriority ] ]
>
> My memories of the previous attempt are coming back now ;-) The above is
> another one of 'em gotchas. If you have more than one process going wild you
> most definitely want to be able to fire off the interrupt handler multiple
> times. Which reminds me of yet another gotcha: "handlerBlock copy fixTemps"
> please or you are for a world of pain ;-)
>

> Cheers,
>  - Andreas
>
>> This makes it irrelevant, at which priority the current event handling
>> running and safe from gotchas, pointed by Andreas (in numerous "Sensor
>> anyFooBar" sends spreaded throughout the image).
>>
>> Also, i think, it would be good to guarantee that there is only single
>> Process which making calls to primitive and fetching events from VM -
>> obviously the event ticker process. The rest processes should be
>> allowed to talk with Sensor only through shared queue.
>

> 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

> Actually it's Michael who is messing in this area to improve the event
> handler for Pharo (and in general) as part of some funding from ESUG for
> the iPhone VM development work.
>
> Me? I'm just an innocent bystander.  I'd assume he has to fork off any
> logic with low io process priority which is what I think happens if you
> follow the bouncing ball by reviewing what  installInterruptWatcher and
> handleUserInterrupt do. The key consideration is that fetchMoreEvents is
> the trigger, not the code in the VM.
>
>
> On 20-Nov-08, at 10:58 AM, Andreas Raab wrote:
>
>> 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 <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>