Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!zephyr.ens.tek.com!tekchips!sail!terryl
From: terryl@sail.LABS.TEK.COM
Newsgroups: comp.unix.internals
Subject: Re: Nice
Message-ID: <8912@sail.LABS.TEK.COM>
Date: 5 Feb 91 19:16:19 GMT
References: <1991Jan22.184055.3641@demott.com> <rdavis.665087618@connie.convex.com> <richard.665126102@fafnir.la.locus.com> <2004@necisa.ho.necisa.oz.au> <1991Jan31.180957.9167@turnkey.tcc.com> <2007@necisa.ho.necisa.oz.au>
Reply-To: terryl@sail.LABS.TEK.COM
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 27

In article <2007@necisa.ho.necisa.oz.au> boyd@necisa.ho.necisa.oz.au (Boyd Roberts) writes:
+In article <1991Jan31.180957.9167@turnkey.tcc.com> jackv@turnkey.TCC.COM (System Administrator) writes:
+>... But it is also not correct that a context
+>switch will take as long as you suggest. What will happen is that the
+>interrupt will cause the kernel to run in trap(),
+
+Device interrupts do not go through trap().  The stack is munged, the
+interrupt routine is called, the stack un-munged and the interrupt is
+returned from.  No calls to trap().  trap() handles exceptions, not
+device interrupts.


     `Tis true (that device interrupts do not go through trap()), but in
almost all modern Unices I've seen, there is a check just right before
returning from the interrupt(and it goes like this, in my best Ray Davies
imitation!!! (-:):

	If we were interrupted in USER mode
			AND
	We need to reschedule the cpu
	then call trap() to reschedule the cpu....

__________________________________________________________
Terry Laskodi		"There's a permanent crease
     of			 in your right and wrong."
Tektronix		Sly and the Family Stone, "Stand!"
__________________________________________________________