Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!apple.com!rmh From: rmh@apple.com (Rick Holzgrafe) Newsgroups: comp.sys.mac.programmer Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions) Message-ID: <6791@internal.Apple.COM> Date: 20 Feb 90 02:19:06 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 37 References:<10193@hoptoad.uucp> <2032@cbnewsk.ATT.COM> <1990Feb13.173605.7633@intercon.com> <10268@hoptoad.uucp> <52320@bbn.COM> <6143@umd5.umd.edu> In article <6143@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes: > 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). > ... > 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. It probably depends on the driver. AppleTalk drivers certainly can and (at their discretion, not always!) certainly do simply run your request before returning from the async PBControl call that makes the request. You should therefore always assume that this can happen, and be sure when you call PBControl that you are fully ready for the completion routine to run (and place the next PBControl call) before that PBControl call returns. Beware of stack overflow from recursion, and remember that from interrupt level you don't know *whose* stack you're running in. What the file system drivers do, I have no idea. > Sig DS.L ('ZBen') ; Ben Cranston > * Network Infrastructures Group, Computer Science Center > * University of Maryland at College Park > * of Ulm ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 67-B | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."