Re: user-written interrupt handlers

[Juergen Lock <nox@jelal.north.de>]

Howard Chu writes:

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

 well whether you'll hear it depends on what you play back :) but when a
cat >/dev/audio uses an interrupt handler that takes too long it will
annoy uucico processes running at the same time as well as when its a
serial interrupt handler with this problem...
> 
> 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...

 btw anyone using the TT's SCC DMA yet?  its too bad mega STe don't have it :)
(and have all this SCC problems too.)
> 
> 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.

 hmm.  if there is no one else hooked into the same vector `above' you
you could reset the interrupt level from the stack after flipping the
68901 in-service bit and then send the signal and rte...  (is post_sig etc
re-entrant(sp?) ?)

>  I guess you could set another flag
> to indicate SLIP or PPP end of frame, and have a VBL routine check that...

 ...and otherwise (interrupt level on stack was >= 5) do this.
> 
> 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...

 maybe the disk driver?  when my quantum disk gets accessed while it
recalibrates i get a few second `sleep' too.  but that has nothing to do
with multitos...

>   -- Howard
 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA