Re: user-written interrupt handlers

[hyc@hanauma.jpl.nasa.gov (Howard Chu)]

>>   Signal handlers aren't good replacements for interrupts; they take too
>>   much time to be serviced -- maybe a tenth of a second, versus a few
>>   microseconds for an interrupt handler. It would be unusable, for
>>   instance, for the serial interrupts, while it would be quite appropriate
>>   for "Monochrome Detect", say.
>> 
>> Well, since my only purpose here was to drive my interrupt-driven sound
>> routines on the Falcon, that was just fine anyway. (Using the monochrome
>> detect interrupt, fancy that.)
>
> btw what is the difference, isn't monochrome detect level 6 too? :)
>(not that this should be a problem here...)
>
> cheers
>	Juergen

Heh. Well, I doubt a monochrome monitor will burn out in a few milliseconds
of bad video signal, and I know you won't hear a few milliseconds lag in
swtching the buffer addresses of a DMA-driven sound playback, but you could
lose several bytes in that amount of time in a serial interrupt handler.

It's too bad there weren't a couple more DMA channels in the regular ST;
like one for the 68901 USART. Running that chip in sync mode would let you
do some really mean high-speed internetworking...

Hm.... Now that I think of it, how could you call post_sig from an rs232
interrupt handler? You need to get back to receiving the characters of
the next incoming frame right away, so you need some way of firing off the
call to post_sig at a lower priority. I guess you could set another flag
to indicate SLIP or PPP end of frame, and have a VBL routine check that...

On a different topic, I've seen my system freeze up completely from time
to time, only to return to regular operation some indeterminate amount of
time later. Anyone else seen this? (I'm still talking MultiTOS here.) No
keypresses or button clicks register, drop-down menus don't drop, etc.,
only the mouse-cursor tracks. Awfully disconcerting...
  -- Howard