Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions)
Message-ID: <10268@hoptoad.uucp>
Date: 16 Feb 90 00:38:10 GMT
References: <10193@hoptoad.uucp> <2032@cbnewsk.ATT.COM> <1990Feb13.173605.7633@intercon.com>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 58

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"