[Vm-dev] Re: [Pharo-project] Event history question
andreas.raab at gmx.de
Thu Nov 20 18:58:01 UTC 2008
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
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
> 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
> 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)
>>> be in the VM.
>>> After some discussions with John I'm pretty sure we can remove the
>>> 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.
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Best regards,
>> Igor Stasenko AKA sig.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
More information about the Vm-dev