Re: Async File IO is not async?

Alex Ivanoff <[email protected]>
Newsgroups gmane.comp.windows.devel.dotnet.clr
Message-ID <[email protected]>
My definition of "true" async IO is that BeginXXX return immediately.

You right, I should have said FileStream constructor is not preparing underlying file handle for async IO properly and BeginWrite/BeginRead are not properly aligning buffer, its size and file pointer for async IO.

Bottom line, I think the implementation of FileStream when the wrapped handle is physical file is broken as far as async IO goes.


-----Original Message-----
From: Discussion of development on the .NET platform using any managed language [mailto:[email protected]] On Behalf Of Peter Ritchie
Sent: Friday, January 18, 2008 10:38
To: [email protected]
Subject: Re: [DOTNET-CLR] Async File IO is not async?

I guess I my definition of "true" async IO is different than yours because
BeginWriteCore what http://support.microsoft.com/kb/156932 details with
overlapped IO, albeit with managed types.  What parts to you consider
not "true"?  The example code for KB156932 doesn't use
FILE_FLAG_NO_BUFFERING, it just describes what it's for.  Plus, BeginWrite
and BeginRead don't create the file, "reflector reveals that BeginWrite
and BeginRead do not satisfy most..." wouldn't lead anyone to think about
FILE_FLAG_NO_BUFFERING...

Overlapped IO simply asks the system to perform the IO asynchronous.  It
decides whether it will or not.  It may decide that it already has that
data in a cache somewhere and simply return data from the cache instead of
directly reading the disk.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.