Just FYI...
All you people posting to comp.sys.15yearoldarguments - you know you're
also cross-posting to the sqlite mailing list, right?
Tim
Mrs. Brisby wrote:
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.
