Path: utzoo!utgpu!watserv1!watmath!att!cbnewsk!ech
From: ech@cbnewsk.ATT.COM (ned.horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: FSWrite moving memory? (was Re: Think C 4.0 questions)
Message-ID: <2032@cbnewsk.ATT.COM>
Date: 12 Feb 90 21:18:12 GMT
References: <10193@hoptoad.uucp>
Organization: AT&T Bell Laboratories
Lines: 41

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=