Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fub!tmpmbx!scuzzy!src From: src@scuzzy.in-berlin.de (Heiko Blume) Newsgroups: comp.unix.internals Subject: Re: Nice Message-ID: <1991Feb02.034527.13918@scuzzy.in-berlin.de> Date: 2 Feb 91 03:45:27 GMT References: <1991Jan22.184055.3641@demott.com> <2004@necisa.ho Organization: Contributed Software Lines: 31 richard@locus.com (Richard M. Mathews) writes: >Thanks for the defense, Jack. To be explicit, look for the call to >aston() in wakeup() in a VAX kernel. This will cause a trap to occur >before ANY user mode instructions are executed; that is what I meant by >"immediately". Before that trap returns to user mode, it will notice >runrun is set and reschedule. since not many people can 'look for the call in a VAX kernel', except with adb... "An AST [asynchronous system trap posted by aston()] is a trap that is delivered to a process the next time that process returns to *user* mode. [...] The system [then] interrogates the runrun flag and *forces* a context switch [...]" [p.90 in the 4.3BSD book]. that is, the process will go to user mode, it won't execute any of it's instructions, it will trap into the kernel and will then be PREEMPTED. (only user mode stuff can be preempted, processes in system calls can not.) >In other systems (such as a few different >80*86 kernels I've seen) both traps and interrupts check runrun before >returning to user mode and can switch context immediately. that's because they permit context switching from the interrupt stack (etc), which the VAX architecture does not permit. but the VAX does ASTs in hardware :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home