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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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




Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
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 <[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
> ===========================================================================
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
In reply to this post by johnmci
2008/11/20 John M McIntosh <[hidden email]>:

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

Good, it makes sense, if we provide enough guarantees that even ticker
process is always running in warm & dry & safe conditions. :)
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 ] ]

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.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
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.

Reply | Threaded
Open this post in threaded view
|

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

Igor Stasenko
2008/11/20 Andreas Raab <[hidden email]>:

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

It depends how long this process should live.
I didn't examined how 'interrupting' works, just my guess that
interrupt should be a short-term process which does a couple of hacky
things and then terminates.
>From this point, there is no need in spawning many of them, and
actually #isAlreadyRunning is to make sure that there is only single
'hacker' process running - to be sure that you don't need to protect
your state with semaphores/mutexes and so on.

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



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

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

johnmci
In reply to this post by Andreas.Raab
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
=
=
=
========================================================================




Reply | Threaded
Open this post in threaded view
|

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

Andreas.Raab
Oh, I'm sorry for the interference then. I thought you were digging
around in this.

Cheers,
   - Andreas

John M McIntosh wrote:

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