Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!umd5!zben From: zben@umd5.umd.edu (Ben Cranston) Newsgroups: comp.sys.mac.programmer Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions) Summary: IO completion chaining observations Message-ID: <6143@umd5.umd.edu> Date: 16 Feb 90 20:07:27 GMT References: <10193@hoptoad.uucp> <2032@cbnewsk.ATT.COM> <1990Feb13.173605.7633@intercon.com> <10268@hoptoad.uucp> <52320@bbn.COM> Reply-To: zben@umd5.umd.edu (Ben Cranston) Organization: University of Maryland, College Park Lines: 23 Expires: I've disassembled lots of programs (and even written a couple) that used the IO completion chaining scheme. In this scheme the IO completion call for the previous IO operation turns around and queues the IO call for the next IO operation (complete with its own completion request to continue the process). I first saw the technique in the predecessor to Responder, which was called 007 at the time and used this technique with Appletalk Manager requests. My MDQS QPR for the Mac uses it extensively. IO Completion runs from interrupts, so how can it turn around and do IO? I always assumed the async requests just put the request buffer on the queue and returned. I assumed they NEVER turned around and started running the actual driver code, as at least one poster has alluded to. I always assumed the driver had a "periodic service" bit set, and so was periodically called at NORMAL level (from SystemTask) and would THEN scan the request queue and do whatever work it could at that point... -- Sig DS.L ('ZBen') ; Ben Cranston * Network Infrastructures Group, Computer Science Center * University of Maryland at College Park * of Ulm