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.

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



-- 
Best regards,
Igor Stasenko AKA sig.