I note that if you filter MSDN Library on ".NET Framework" that there are no hits for FILE_FLAG_OVERLAPPED, and the single hit for CreateFile is in a sample program showing that calling ReadFile is unsafe. For reasons that are not explained, the declaration of the CreateFile call is also marked unsafe -- I don't think there's anything unsafe about it, as there are no memory references involved (unless you want to pass security attributes).
At 07:54 AM 9/8/2004, John Davis wrote >Got asked for more details. > >If you look at the latest docs on FileStream.BeginRead it says ... > >By default, FileStream opens the operating system handle synchronously. In Windows, >this slows down asynchronous methods. If asynchronous methods are used, use the >FileStream(IntPtr, FileAccess, Boolean, Int32, Boolean) constructor. > >This implies that the IntPtr needs to be a file handle from a call to CreateFile >where the FILE_FLAG_OVERLAPPED was specified. Looks like the current implementation >defaults to async requests (ie FileStream.BeginRead) occuring in the thread pool via >blocking calls to the file handle. I would prefer to have my async operations fire >through an IO completion port, like the socket implementation. Usually more >efficient if done this way. > > >John Davis <[EMAIL PROTECTED]> wrote: >Is it possible to get the IntPtr file handle for this call without doing interop? > > >[C#]public FileStream( IntPtr handle, FileAccess access, bool ownsHandle, int >bufferSize, bool isAsync); J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
