|
From: Phillip S. <ps...@cf...> - 2001-11-11 15:46:31
|
At 11:28 AM 11/11/2001 +0100, you wrote: >For asynchronous i/o the FSD can't only queued up to request to the >underlaying driver. At some points, the FSD must synchronisize the access >to some internal structures. With which other functions as a thread can the >FSD wait for acquireing a synchronisation object, such a ersource? At the >moment, vfat ask for acquireing the eresource and when the caller can't >wait for completion of the request, vfat queue the request as a thread to >the system worker queue. The thread wait for acquireing the eresource >object. I doesn't know an other function, that can do this. I thought that acquiring an ERESOURCE was like a spin lock - it can be done from any IRQL and does not context switch. Even if it does though, this would only introduce the context switching in the rare event of contention of the resource, most of the time the FSD will directly queue the IO to the device driver, and return to the caller with no context switching. Also in the event of contention on the resource, you can do one better than having another thread block waiting for the resource. Instead you can insert the request into an interlocked queue of requests waiting on the resource, and when the resource is released, the next request will be handled right then and there. This is how system IRP queuing and serialization to adapter objects works. >An other way is, that the chache manger add/merge the pages from some cache >segments within one mdl and then call the FSD with this large mdl for a >paging io. For paging io as a result from page faults in section views, the >memory manger should read and map more then one page. So it sounds like you want to rewrite the cc to work the way NT's does: map views of the data to cache and fault it in? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |