Newsgroups: comp.sys.mac.programmer
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!terminator!um.cc.umich.edu!Gavin_Eadie
From: Gavin_Eadie@um.cc.umich.edu (Gavin Eadie)
Subject: Re: File System Re-entrancy
Message-ID: <1989Nov29.151058.23793@terminator.cc.umich.edu>
Sender: news@terminator.cc.umich.edu
Organization: U of Michigan Computing Center
References: <924@maytag.waterloo.edu>
Date: Wed, 29 Nov 89 15:10:58 GMT

In article <924@maytag.waterloo.edu> jb@aries5.uucp writes:
> In other words if I do a PBRead() to a device driver can that device
> driver synchronously do another PBRead() to another device driver?  
> 
> From what I have observed this is non-trivial, because the second
> PBRead() will block becasue FSBusy is set.
> 
> Jim Bruyn

I wrestled with this for a while too. It turns out that, since the file 
system is not re-entrant, you have to cheat if you want to "call PBRead 
from inside PBRead". I needed to be able to do this in order to implement 
a file caching system for the Mac, actually for a Mac implementation of 
the Andrew File System (AFS), and found it to be impossible with the 
present Mac file system.

Under the AFS, an application would call RBRead to get some file stuff, 
the AFS would intercept that call (using the external file system 
mechanism - to be called the foreign file system mechanism in System 7.0), 
determine if the file was cached locally and if it was, call RBRead AGAIN 
to actually obtain the file stuff.

With the help of clever people in Developer Support at Apple, we managed 
to concoct a very small program which kinda worked. The trick was to make 
asynchronous RBRead calls and to call PBRead again in the completion 
routine. The FSBusy block is released before the completion routine is 
invoked.

This curious program was set up to read one character, then read one more 
in the completion routine of that read ad nauseam, stack overflow or eof, 
whichever came first. When run it was quite good at reversing the order of 
all the characters in a file being read! While fun to build, this has no 
real utility since it relied on the PBRead calls being asynch and for the 
mechanism to be generally useful you can't assume all applications do 
this, in fact most don't.

This won't change in System 7.0, but I suggest lobbying for a re-entrant 
file system/device manager in System 8.0. The Mac file system is due for 
an overhaul anyway - it doesn't scale up well to very large file systems. 
An ISO CDROM with a few thousand files on it takes a long time to mount 
and you should watch my Mac as it struggles to mount a distributed file 
system that covers the Universities of Michigan, CMU, MIT and Dartmouth, 
plus a few other sites, as one AppleShare volume! Would you believe 3 
minutes on a good day!!

---
Gavin Eadie, Associate Director/Software Engineer
The University of Michigan Computing Center
535 West William Street, Ann Arbor, Michigan 48109-4943
(313) 936-0816