[Vm-dev] Re: [Pharo-project] Event history question
siguctua at gmail.com
Thu Nov 20 20:10:43 UTC 2008
2008/11/20 Andreas Raab <andreas.raab at gmx.de>:
> 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 ;-)
It depends how long this process should live.
I didn't examined how 'interrupting' works, just my guess that
interrupt should be a short-term process which does a couple of hacky
things and then terminates.
>From this point, there is no need in spawning many of them, and
actually #isAlreadyRunning is to make sure that there is only single
'hacker' process running - to be sure that you don't need to protect
your state with semaphores/mutexes and so on.
> - 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.
Igor Stasenko AKA sig.
More information about the Vm-dev