2008/11/20 Michael Rueger <m.rueger@acm.org>:

Hi all,

the event handling rewrite slowly starts to work :-) I'm currently fighting the parts where polling is used (like moving a window), but more on that later.

The question I have is about user interrupt handling. I'm a bit confused and don't remember the history there: was there first an interrupt semaphore that then was abandoned or was it introduced but then not supported on some platforms?

Or phrased differently: do we want user interrupt go through an interrupt semaphore or rather handle it on the image side?

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.

Michael

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

2008/11/20 Michael Rueger <m.rueger@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

2008/11/20 John M McIntosh <johnmci@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

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.