2008/11/20 John M McIntosh <[EMAIL PROTECTED]>: > > 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. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
