(Illustration by Gaich Muramatsu)
None of the clients you mention use a user level program to service kernel calls [which effectively sit below the mutex that is taken]. Coda could in principle be implemented in the kernel, like they are. From practical perspectives that would be a disaster. There will be a release of the 95 code for Coda that actually works in about 6 weeks from now. A visiting student to our group Marc Schnieder has made good progress fixing a few bugs and implementing some missing components. - Peter - On Thu, 8 Oct 1998, Shyh-Wei Luan wrote: > Hi, > > The following is some excerpts from some Coda's document (I think > Michale Callahan wrote it) for the decription of a deadlock problem in doing > a user-level Windows 95 port and the rationale for going with > a DOS application implementation of most of the Coda client code. > > -------------- excerpts start ---------- > "Why DOS applications?? It would seem more straightforward to > implement the Coda client cache manager, a user level program named > Venus, as a Win32 application. Sadly on Windows 95 we ran into the > following (fairly well known) problem. When a user application calls > a Win32 file system call, the application may acquire a mutex in a > win16 system dll. The request should reach the kernel, and make its > way up to Venus. Venus is then unable to service the request because > it cannot grab the mutex. Deadlock results." > --------------- excerpts end ------------ > > This makes me wonder how NFS and Netware clients are implemented on Windows 95. > Did they implement the whole thing in the kernel or somehow they got a solution > to the problem? If so, can't Coda use the same solution? Is the deadlock > problem somehow unique to Coda? > > Shyh-Wei Luan > > -- >Received on 1998-10-08 15:47:20