[squeak-dev] Re: [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 ;-)
Cheers,
- 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 Squeak-dev
mailing list
|