On Sat, 2005-07-30 at 20:29 +0200, Jan-Eric Duden wrote:
> Mrs. Brisby wrote:
> 
> >On Sat, 2005-07-30 at 14:30 +0200, Jan-Eric Duden wrote:
> >  
> >
> >>Win9X doesn't support the API async file operations.
> >>WinNT/2K/XP does support it.
> >>    
> >>
> >
> >It supports everything it needs to:
> >
> >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjects.asp
> >
> >
> >it doesn't support async file NOTIFICATIONS, (afaik), but those aren't
> >necessary...
> >
> >  
> >
> How should waitformultipleobjects help with aync file io?

It doesn't. Read below.

> For async file io on Win32 you would open a file with CreateFile and 
> pass the  FILE_FLAG_OVERLAPPED flag.
> After that, functions like WriteFile and ReadFile work asynchronously. 
> Unfortunately, on Win9X/ME it is not supported for files on disk.
> For example, see the docs of WriteFile/ReadFile/WriteFileEx/ReadFileEx:
> *"Windows 95/98/Me: *For asynchronous write operations, /hFile/ can be a 
> communications resource opened with the FILE_FLAG_OVERLAPPED flag by 
> *CreateFile*, or a socket handle returned by *socket* or *accept*. You 
> cannot perform asynchronous write operations on mailslots, named pipes, 
> or *disk files*. "

No you don't. It's not just that Windows 3.11/95/98/ME don't support
FILE_FLAG_OVERLAPPED - its that their filesystem isn't reentrant. It
cannot do a context switch during that either.

You use a large read-size (bigger than the disk-block) and it can
context-switch inbetween disk operations. Threads look like a win here!

You can also use the disk-block reads. The operating system you're
talking about is uniprocessor only. Process control returns to your
program just as fast as a thread-switch can occur, and you've saved a
context-switch.

Use waitformultipleobjects to check your event pump after each readFile
or writeFile operation.

[[ as a side note: no, it's not really that easy. If the disk is asleep,
spun down, or if you run two programs you need to do extra work:
        * wake up the disk
        * lock the underlying physical disk
Because your code is simpler, these things aren't such a big deal. ]]


I will personally advocate splitting processes into a worker-master
situation- I just don't recommend pool-threading. That's a lie. I
recommend against pool-threading.

Reply via email to