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

Andreas Raab andreas.raab at gmx.de
Thu Nov 20 19:57:17 UTC 2008

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

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

More information about the Vm-dev mailing list