Subbarao Meduri wrote:
> 
> If I understand correctly, code win95 client is
> blocking in ring 0 (kernel) for servicing I/O requests
> from a user space process (ring 3). This should cause
> a deadlock since win95 kernel32 acquires a global
> lock before dispatching I/O request to kernel and
> expects the I/O request to be serviced completely from
> kernel mode.
> 
> If it is of any value, following URL has a thread on
> why this cannot be done.
> http://www.pcausa.com/resources/r3hang.txt
> 
> Can someone comment on why this is not a
> problem with the current win95/98 coda client ?
> 

The thread you mentioned includes the answer. The win9x client must not
be a win32 application. It therfore is a DMPI (DOS Protected Mode
Interface) application, which is a 32 bit program but not win32.

Also according to the thread you mentioned, the global lock (not the
Win16Mutex) prevents thread context switches, which is why a win32
applications that should serve a FSD will never receive the call. In the
same time no other win32 thread will be scheduled and the graphical user
interface and all win32 apps freeze.

Venus, being a DPMI application, is immune to this behavior since it
runs in a seperate virtual machine.

The Win16Mutex (not the global lock metioned above), which might be held
by certain file system requests (because they employ 16-bit code) could
cause problems too. Many Win32 API functions employ 16-bit code. A win32
Venus (if scheduled) could call one of these win32 API function on its
way serving the request. Deadlock would occur because Venus blocks on
the Win16Mutex. 
A DPMI client does not call Win32 API functions and will never try to
get the Win16Mutex. DPMI programs call certain interrupts to perform
file system requests (Venus does many file system request on the local
drive when storing copies in its cache for example). These interrupts
are handled in ring0 and do not employ 16-bit code.

Marc