urlichs@smurf.ira.uka.de (02/10/90)
In comp.sys.mac.programmer, article <90039.151841CXT105@PSUVM.BITNET>,
CXT105@psuvm.psu.edu (Christopher Tate) writes:
< In article <10111@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) says:
<
< >Why do you say FSWrite can move memory? It's not in the lists, so unless
< >it's in an unlocked segment, I don't see how (or why!) it would move memory.
<
< According to Apple, the operating system has been patched from here to
< hell and back again, and the lists are no longer valid. A much safer
< way to go is to assume that any trap routine can move memory, and set
< things up to deal with this possibility.
<
Not in this case. All file system calls are supposed to be callable from
interrupt, and so they (as well as any patch sitting on them)_can't_ move
memory.
Unfortunately, I wonder if they still could possibly move memory in the
synchronous case, which may not be called from interrupt.
If the disk to be written to isn't online, the Mac will display its nice
"Please insert the disk" alert. It would be interesting to know if this can
make any memory manager calls, and if so, in what heap.
Things aren't as easy as they seem to be -- at first I agreed with Tim, but
I'm not sure anymore. Gotta test this sometime.
--
Matthias Urlichsoster@dewey.soe.berkeley.edu (David Phillip Oster) (02/12/90)
In article <1510@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes: >In comp.sys.mac.programmer, article <90039.151841CXT105@PSUVM.BITNET>, >CXT105@psuvm.psu.edu (Christopher Tate) writes: >< In article <10111@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) says: >< >< >Why do you say FSWrite can move memory? It's not in the lists, so unless >< >it's in an unlocked segment, I don't see how (or why!) it would move memory. >< >< >Not in this case. All file system calls are supposed to be callable from >interrupt, and so they (as well as any patch sitting on them)_can't_ move >memory. Wrong! Wrong! Wrong! The file system calls can not be called from interrupt level. Neither the SCSI manager, nor the file manager does the semaphoring to properly lock important data structures so that your disk will not be scrambled by interrupt level access. In addition, the mac uses a B-Tree catalog to manage file extents. Where do you thing it is going to put that B-Tree? As the file gets large, the structures that describe where that file is on disk _must_ grow. This will move memory. (I wouldn't be so emphatic about it, but it might be _my_ hard disk that crashes as a result of running a program that has this error in it.) >Unfortunately, I wonder if they still could possibly move memory in the >synchronous case, which may not be called from interrupt. >If the disk to be written to isn't online, the Mac will display its nice >"Please insert the disk" alert. It would be interesting to know if this can >make any memory manager calls, and if so, in what heap. Since these are just resources, they certainly will move memeory unless they've already been read in and locked in. There is a system call: CanAlert(), to preread such things. Does your program call it? --- David Phillip Oster -- No, I come from Boston. I just work Arpa: oster@dewey.soe.berkeley.edu -- in cyberspace. Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
tim@hoptoad.uucp (Tim Maroney) (02/12/90)
In article <34240@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >> All file system calls are supposed to be callable from >>interrupt, and so they (as well as any patch sitting on them)_can't_ move >>memory. > >Wrong! Wrong! Wrong! The file system calls can not be called from >interrupt level. Neither the SCSI manager, nor the file manager does the >semaphoring to properly lock important data structures so that your disk >will not be scrambled by interrupt level access. Uh, David, you know I have the greatest respect for you, but would you mind providing some substantiation for this astounding claim? The basic data structure, the file system request queue, is properly locked to make sure that no two requests can try to get at the file system at the same time. None of the internal file system code allocates any memory, and the only reentrant code is that which tacks the parameter blocks onto the queue and takes them off the front -- and that is indeed locked properly, by Enqueue and Dequeue. The file system always has been and always will be callable from the interrupt level. >In addition, the mac >uses a B-Tree catalog to manage file extents. Where do you thing it is >going to put that B-Tree? As the file gets large, the structures that >describe where that file is on disk _must_ grow. This will move memory. No, this is a definite miss. The files grow on disk. The entire files do not have to be, and frequently are not, in RAM. That's one of the advantages of a B-tree structured index -- even if you have to resolve every level of the index with disk fetches, there are still not many fetches and it goes pretty fast. No memory is *ever* allocated by the file system using the Memory Manager. Even the cache is preallocated, and managed in an interrupt-friendly way. >(I wouldn't be so emphatic about it, but it might be _my_ hard disk that >crashes as a result of running a program that has this error in it.) If it's been losing you any sleep, you may now rest easy.... >>Unfortunately, I wonder if they still could possibly move memory in the >>synchronous case, which may not be called from interrupt. >>If the disk to be written to isn't online, the Mac will display its nice >>"Please insert the disk" alert. It would be interesting to know if this can >>make any memory manager calls, and if so, in what heap. > >Since these are just resources, they certainly will move memeory unless >they've already been read in and locked in. There is a system call: >CanAlert(), to preread such things. Does your program call it? This is another definite miss. It's actually a system error alert, as stated in IM II-80 and IV-92. System error alerts are described in the system error alert table, a non-relocatable, pre-allocated, and pre-initialized structure. System error alerts don't move any memory under any circumstances, and they don't use resources. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The above opinions and suggestions have absolutely nothing to do with the little fat man putting crisp $100 bills in my pocket." -- Alan Vymetalik
ech@cbnewsk.ATT.COM (ned.horvath) (02/13/90)
Since it was my rash remark that started all this, let me try to calm the waters a bit. FSWrite is NOT on the list of traps that move memory. This is hardly surprising, since FSWrite is [Not in ROM] and always was the "high level" interface to PBWrite, which IS in ROM. PBWrite is also not on the list of traps that move memory. However, just to give you an idea of what that means, notice that PBOpen is on the list. No surprise, PBOpen has to allocate various structures. Notice also that PBHOpen is NOT on the nasty trap list. A courageous programmer would assume that PBHOpen is nicer than PBOpen. I'm too pessimistic for that. To digress a moment, PBOpen also has an "asynchronous" option, which would seem to contradict Tim Maroney's conjecture that async implies "does not move memory." HFSDispatch, the one-trap interface to things like PBGetCatInfo, can be async, too. But scanning the B-tree, however well-behaved, is not something I'd try at interrupt time, nor would I be inclined to depend on it being well-behaved. To return the original issue, I messed up. FSWrite/PBWrite aren't on the lists. There are two reasons why I messed up, and I'd like to tell you what they are. I have been known to write Drivers. Drivers receive PBWrite commands. Perhaps write is not supposed to move or purge memory, but when you depend on this "fact" you are trusting people like me, who forget that Write isn't supposed to move or purge memory. I frequently write asynchronous PBWrite calls (I do lots of communications programming, and the serial ports implement async I/O quite nicely). If you are going to do async I/O, you may not have to lock the buffer, but if the buffer isn't locked the rest of my program can't do anything that moves memory while the I/O is in progress. Hence the simple-minded habit I have of either preallocating buffers (with NewPtr) or of locking before write and unlocking after completion. People with a better grasp of detail won't need to cultivate habits like this. Sorry about the furor. I'll stick to religion and politics, I guess. =Ned Horvath=
amanda@mermaid.intercon.com (Amanda Walker) (02/14/90)
In article <2032@cbnewsk.ATT.COM>, ech@cbnewsk.ATT.COM (ned.horvath) writes: > To digress a moment, PBOpen also has an "asynchronous" option, which > would seem to contradict Tim Maroney's conjecture that async implies > "does not move memory." I think we still have a small confusion here. When you make a file system call asynchronously, all it does is insert the request into the file system queue. *That* operation does not move memory, which is why you can do it at interrupt time (along with the fact that Enqueue & Dequeue handle interlocking on the queue). The actual file operations themselves may (although I don't know, offhand, never having dug into the file system code myself), but they are not done at interrupt time. The file system doesn't do "real" :-) asynchronous I/O, but it does let you queue up operations asynchronously. -- Amanda Walker InterCon Systems Corporation "Many of the truths we cling to depend greatly upon our own point of view." --Obi-Wan Kenobi in "Return of the Jedi"
urlichs@smurf.ira.uka.de (02/14/90)
In comp.sys.mac.programmer, article <34240@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: < In article <1510@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes: < >In comp.sys.mac.programmer, article <90039.151841CXT105@PSUVM.BITNET>, < >< < >Not in this case. All file system calls are supposed to be callable from < >interrupt, and so they (as well as any patch sitting on them)_can't_ move < >memory. < < Wrong! Wrong! Wrong! The file system calls can not be called from < interrupt level. Neither the SCSI manager, nor the file manager does the The SCSI manager does not. That's true, and to be fixed in 7.0. However, the file manager does. It has a global queue with file system requests in it and only works on the first one. Since _Enqeue and _Dequeue lock out interrupts while they run, there's your semaphoring. And as long as nobody else uses the SCSI manager, there are no problems. So I can just shout "Right! Right! Right!" here... (NB: I was talking about the low-level file manager calls with async set to TRUE. The high-level calls reduce to low-level calls with async=FALSE, which obviously is not good when called from an interrupt.) < semaphoring to properly lock important data structures so that your disk < will not be scrambled by interrupt level access. In addition, the mac < uses a B-Tree catalog to manage file extents. Where do you thing it is You can manage a B-tree easily without caring for its size. All you have to do is to store a pointer to the next upper level in each node instead of remembering them in memory.. < going to put that B-Tree? As the file gets large, the structures that < describe where that file is on disk _must_ grow. This will move memory. < (I wouldn't be so emphatic about it, but it might be _my_ hard disk that < crashes as a result of running a program that has this error in it.) < Sorry, but I had this server of mine run in interrupt level for hours, letting three clients create folders, files, read them, write them, delete them again, without any problems at all. (Expect numerous flames from people who try to tell you that you don't seem to know what you're talking about. Oops, that sounds too much like Tim Maroney -- sorry.) < >Unfortunately, I wonder if they still could possibly move memory in the < >synchronous case, which may not be called from interrupt. < >If the disk to be written to isn't online, the Mac will display its nice < >"Please insert the disk" alert. It would be interesting to know if this can < >make any memory manager calls, and if so, in what heap. < < Since these are just resources, they certainly will move memeory unless < they've already been read in and locked in. There is a system call: < CanAlert(), to preread such things. Does your program call it? < No. The routine is called CouldAlert(), and it's for ordinary alerts, which the "Please insert disk" window is definitely _not_. -- Matthias Urlichs
urlichs@smurf.ira.uka.de (02/14/90)
In comp.sys.mac.programmer, article <10193@hoptoad.uucp>, tim@hoptoad.UUCP (Tim Maroney) writes: < In article <34240@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP < (David Phillip Oster) writes: < >Matthias Urlichs writes: < >>Unfortunately, I wonder if they still could possibly move memory in the < >>synchronous case, which may not be called from interrupt. < >>If the disk to be written to isn't online, the Mac will display its nice < >>"Please insert the disk" alert. It would be interesting to know if this can < >>make any memory manager calls, and if so, in what heap. < > < >Since these are just resources, they certainly will move memeory unless < >they've already been read in and locked in. There is a system call: < >CanAlert(), to preread such things. Does your program call it? < < This is another definite miss. It's actually a system error alert, as < stated in IM II-80 and IV-92. System error alerts are described in the < system error alert table, a non-relocatable, pre-allocated, and < pre-initialized structure. System error alerts don't move any memory < under any circumstances, and they don't use resources. This is what the docs say. I just wonder why, in the synchronous case, I get a "Please insert the disk" error, while in the async case (and even when calling PBxxx(PB,TRUE) from my main event loop or something) I do in fact get PB.ioResult = volOfflinErr. Something must be going on here. It can't be interrupts, since the System could simply stick the request to bring up the alert into the deferred task manager queue or something. Anyone in the know ? Could it possibly be because that system error alert is invalidating whatever was behind it, which definitely would move memory? (Such invalidation could of course be deferred until the next GetNextEvent, but this is not what's happening.) -- Matthias Urlichs
francis@mirror.UUCP (Joe Francis) (02/14/90)
In article <1990Feb13.173605.7633@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >The file system doesn't do "real" :-) asynchronous I/O, but it does let you >queue up operations asynchronously. Is "real" asynchronous I/O anything like "real" multitasking??? 8-) (oh boy, did someone say "FlameFest"???!!!) PS: Mac and/or MS Windows programmer for hire... inquire within ----------------------------------------------------------------------------- SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! SPAM! Joe Francis "Nobody expects the francis@prism.tmc.com Spammish Repitition!"
urlichs@smurf.ira.uka.de (02/15/90)
In comp.sys.mac.programmer, article <1990Feb13.173605.7633@intercon.com>,
amanda@mermaid.intercon.com (Amanda Walker) writes:
<
< The actual file operations themselves may [ move memory ]
< (although I don't know, offhand, never having dug into the file system
< code myself), but they are not done at interrupt time.
<
Yes they are.
Consider the following fragments from Program A:
REPEAT
SCSIselect()
SCSIget()
...
SCSIcomplete();
UNTIL Picture_all_here; (* common loop when talking to scanners *)
Consider the following fragments from Program B:
ATPGetRequest(async,completion_routine);
completion_routine:
PBread(async);
Both are perfectly legal, but if Program A and Program B run under MultiFinde
at the same time, and Program B gets an ATP request packet, things start to
hang because (a) Program A's loop, which does not call GetNextEvent or
anything, is interrupted, (b) neither the hard disk's SCSI driver nor the file
system test if the SCSI bus is free, (c) file system requests do get processed
at interrupt time.
The above happened to me. The workaround seemed to be
completion_routine:
IF SCSIBusy() AND (FileSystemQueue Empty) THEN
put_in_queue_and_try_again_later
ELSE
PBread();
The above code, unfortunately, can lead to race conditions (when testing, SCSI
is free but when HFS gets around to accessing the disk, the bus is not).
I don't think there's any fix for this other than the new SCSI manager from
System 7.0...
< The file system doesn't do "real" :-) asynchronous I/O, but it does let you
< queue up operations asynchronously.
<
Yes it does; the SCSI manager does not. (You can do "real" async IO with
your regular disk drives.)
Some people, of course, would define "real async" as "requiring DMA".
Are there any DMA-SCSI NuBus boards out yet? Do they work with A/UX? Will they
work with Sys 7.0? (Its SCSI manager should make it fairly easy to hook such a
board into the OS, without resorting to trap patching or disabling the
built-in SCSI port. That's a good thing, because I already have 8 SCSI devices
including the Mac, and need to connect two more. :-(
--
Matthias Urlichstim@hoptoad.uucp (Tim Maroney) (02/16/90)
In article <2032@cbnewsk.ATT.COM>, ech@cbnewsk.ATT.COM (ned.horvath) writes: >> To digress a moment, PBOpen also has an "asynchronous" option, which >> would seem to contradict Tim Maroney's conjecture that async implies >> "does not move memory." In article <1990Feb13.173605.7633@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >I think we still have a small confusion here. When you make a file system >call asynchronously, all it does is insert the request into the file system >queue. *That* operation does not move memory, which is why you can do it >at interrupt time (along with the fact that Enqueue & Dequeue handle >interlocking on the queue). The actual file operations themselves may >(although I don't know, offhand, never having dug into the file system >code myself), but they are not done at interrupt time. Yes and no. My understanding is that in many cases, an async call will actually run as soon as it is queued, and that this all depends on the behavior of the driver involved. PBOpen, as well as the other PB traps on the list, are a little different from the others on the list in that the determination of whether they can move memory is made on a case-by-case basis. PBOpen to the file system won't move memory; I'm not sure where the FS gets the access path buffer from, but note that if it were being gotten from the memory manager, PBClose would also be on the list because the buffer would be deallocated then. (It's also easy to check with MacsBug and see that no memory-moving traps are called during a PBOpen to the file system -- I just did.) PBOpen to a desk accessory, however, definitely will move memory. To a driver, it probably will. Similarly, PBControl and PBStatus may or may not move memory depending on the behavior of the driver in question. (Actually, given that closing a desk accessory or driver can release memory, I don't know why PBClose isn't on the list. Ideas?) So the answer seems to be that you can PBOpen a file from the interrupt level, so long as you do it async to prevent deadlock, but you can't PBOpen a desk accessory or most drivers from the interrupt level, period, because even if you request it async, it may run right away. There's no "defer to synchronous level" mechanism in the MacOS, except for running from SystemTask, and the file and device request queues are polled in response to requests only, not from SystemTask. >The file system doesn't do "real" :-) asynchronous I/O, but it does let you >queue up operations asynchronously. Sort of. You still can't queue up a request asynchronously from the interrupt level if the request isn't allowed at the interrupt level. (Too bad Gary Fitts doesn't post to the net, or we could clean this whole discussion up in about a microsecond.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Now hear a plain fact: Swedenborg has not written one new truth: Now hear another: he has written all the old falshoods. And now hear the reason. He conversed with Angels who are all religious, & conversed not with Devils who all hate religion..." - Blake, "The Marriage of Heaven and Hell"
tim@hoptoad.uucp (Tim Maroney) (02/16/90)
In article <1528@smurf.ira.uka.de> urlichs@smurf.ira.uka.de writes: >< This is another definite miss. It's actually a system error alert, as >< stated in IM II-80 and IV-92. System error alerts are described in the >< system error alert table, a non-relocatable, pre-allocated, and >< pre-initialized structure. System error alerts don't move any memory >< under any circumstances, and they don't use resources. >I just wonder why, in the synchronous case, I get a "Please insert the disk" >error, while in the async case (and even when calling PBxxx(PB,TRUE) from my >main event loop or something) I do in fact get PB.ioResult = volOfflinErr. > >Something must be going on here. It can't be interrupts, since the System >could simply stick the request to bring up the alert into the deferred task >manager queue or something. Anyone in the know ? The deferred task manager queue also runs at the interrupt level (remember, interrupt level 0 is still the interrupt level if you're fielding code from an interrupt), and came years after the current file system implementation anyway. Obviously the system is (wisely) leery of freezing the whole system at the interrupt level and waiting for the user, who's slow as mountains. Also, you could easily be locking out the floppy driver at a high interrupt level; it's never a good idea to sleep at the interrupt level. So I imagine the way it gets around this is to check the async bit in the trap word stored in the ioTrap field of the parameter block, and simply returns an error if it's set, reasoning that all interrupt-level code would be doing async requests. >Could it possibly be because that system error alert is invalidating whatever >was behind it, which definitely would move memory? (Such invalidation could of >course be deferred until the next GetNextEvent, but this is not what's >happening.) That's an interesting question. It must have a preallocated saved-bits bitmap/pixmap to restore the screen. Or not. I just checked; SysError is in fact on the list of traps that can move or purge memory. But can't this alert come up in response to any operation on an offline volume, not just open? Yes, according to IM IV-92. So this could happen in response to *any* file system operation, practically. Christ. But the system error chapter spells out exactly what SysError does, and it doesn't say anything about allocating heap memory or saving bits. I doubt it would, since it will often be called when a heap is corrupted. So *something* is wrong here; either all the file system traps should be on the list, or SysError shouldn't be. Isn't there some file system internals guru from Apple reading this confusion who can help? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The government of the United States is not, in any sense, founded on the Christian religion." -- George Washington
levin@bbn.com (Joel B Levin) (02/16/90)
In article <10268@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: |...not sure where the FS gets the access path buffer from, but note that !if it were being gotten from the memory manager, PBClose would also be |on the list because the buffer would be deallocated then. . . . and |(Actually, given that closing a desk accessory or driver can release |memory, I don't know why PBClose isn't on the list. Ideas?) I don't have my Inside Mac and Technotes etc. here, but it seems to me that RELEASING memory would not result in MOVING memory; I thought this could only happen when something needs memory and there is not a big enough piece available. /JBL (probably full of beans) = Nets: levin@bbn.com | "There were sweetheart roses on Yancey Wilmerding's or {...}!bbn!levin | bureau that morning. Wide-eyed and distraught, she POTS: (617)873-3463 | stood with all her faculties rooted to the floor."
zben@umd5.umd.edu (Ben Cranston) (02/17/90)
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 <zben@Trantor.UMD.EDU>
* Network Infrastructures Group, Computer Science Center
* University of Maryland at College Park
* of Ulmtim@hoptoad.uucp (Tim Maroney) (02/19/90)
In article <10268@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >|...not sure where the FS gets the access path buffer from, but note that >|if it were being gotten from the memory manager, PBClose would also be >|on the list because the buffer would be deallocated then. . . . > > and >|(Actually, given that closing a desk accessory or driver can release >|memory, I don't know why PBClose isn't on the list. Ideas?) In article <52320@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >I don't have my Inside Mac and Technotes etc. here, but it seems to me >that RELEASING memory would not result in MOVING memory; I thought >this could only happen when something needs memory and there is not a >big enough piece available. No, I checked this before writing the above, and DisposPtr and DisposHandle are on the move/purge memory routine list. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "I don't know that atheists should be considered citizens, nor should they be considered patriots. This is one nation under God." -- George Bush in FREE INQUIRY magazine, Fall 1988
paul@taniwha.UUCP (Paul Campbell) (02/19/90)
In article <10302@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <52320@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >>I don't have my Inside Mac and Technotes etc. here, but it seems to me >>that RELEASING memory would not result in MOVING memory; I thought >>this could only happen when something needs memory and there is not a >>big enough piece available. > >No, I checked this before writing the above, and DisposPtr and DisposHandle >are on the move/purge memory routine list. I always thought that they weren't just worried about moving memory but about doing things in the memory manager which were not locked (for example they are halfway through updating some memory manager data structure when an interrupt comes along that delivers your completion routine, you dispose your handle and trash the half updated structure). Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P You know there's something wrong when 100,000 people marching in Moscow make page 1 and 400,000 in Washington don't .....
rmh@apple.com (Rick Holzgrafe) (02/20/90)
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 <zben@Trantor.UMD.EDU> > * 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."