[ros-kernel] Re: making vfat asynchronous

[Phillip S. <ps...@cf...>]

At 06:57 PM 11/8/2001 +0100, you wrote:
>A FSD handle all accesses to files synchronous. There are some differences
>between read/write and paged/nonpaged operations. When the caller can't
>block, the FSD handle the request in created thread. Why can't a FSD not
>use the worker queue from kernel?

Our FSD is synchronous, yes, but it should not be.  Implementing async 
behavior by switching to another thread, which then blocks is a very poor 
kludge.  A while back async IO on Linux was implemented just this way in 
libc, and as a result, noone used it because it sucked.  WSAAsyncSelect() 
in winsock is also implemented by having another thread call select, which 
is why it doesn't scale well either.  Async IO really needs to be done 
anachronously, with no thread switching.  This means that the FSD code 
needs to be rewritten so that if it needs to do IO, it queues up the 
request to the underlying driver, and returns STATUS_PENDING, rather than 
blocking on sync IO to the underlying device, even if this is done in 
another thread.

When using the other thread blocks kludge, async IO ends up causing a 
thread switch, just so the other thread can queue up the request, and then 
switch back.  This adds the overhead of 2 switches per async IO call, and 
also requires a pool of threads that must literally sit around with their 
thumbs up their rear ends most of the time.  This finite pool of threads 
then limits the number of pending async IO calls, and wastes resources on 
threads that do very little work.

>Correct, the vfat driver must be rewritten. But the driver needs also more
>support from kernel. There is no implementation of a cache manager like NT,

I think this is no longer the case.  While David has implemented the ros 
cache manager differently than the way NT does it ( which I vehemently 
disagree with ), didn't you recently add CcCopy* interfaces to the cache 
manager?  So what else is missing?

>the security functions doesn't work and many other functions doesn't work

Security functions we don't need to worry about just yet, and can easily be 
added later with only small changes to the code.  What other functions 
don't work right all of the time, and when do they fail?

>under special conditions. I think, at the moment it's better to add some
>function to vfat in small steps and test it with the current kernel.
>
>- Hartmut

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================