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

Igor Stasenko siguctua at gmail.com
Thu Nov 20 19:42:27 UTC 2008

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

More information about the Vm-dev mailing list