----- Original Message -----
From: "Doug Nebeker" <[EMAIL PROTECTED]>
Two comments:
* This should only be used for Windows CE as-is. On Windows
XP/2000/2003(?)/Terminal Services you should probably add "Global\"
to the front of the mutex name so the lock is truly system wide.
Unforunately, you'd have to query Windows to see whether that prefix
could/should be added, but that is doable.
Correct -- this code path would not be available for non-CE platforms. For
testing purposes however, it'll run on any flavor of Windows. The code is
designed around SQLite's use of those API calls under the NT codepath.
* Although it is unlikely, the complete mutex name could end up
being larger than MAX_PATH in which case the mutex won't be created
at all. Maybe creating a hash of the path would be safest (ie
"Global\sqlite_X4F12F9AB481727BCD" or something like that).
It is pretty highly unlikely, but I suppose hashing the name is a
possibility.
I incorporated the locks into the latest CVS version of os_win.c and it's
available here:
http://sqlite.phxsoftware.com/os_win.c
During testing I discovered something rather important and had to modify my
code accordingly.
I mistakenly assumed that the following two API calls would succeed (when
called in sequence):
res = LockFile(hFile, PENDING_BYTE, 0, 1, 0);
res = LockFile(hFile, PENDING_BYTE, 0, 1, 0);
I assumed that because the first call obtained the lock, that the 2nd call
would merely increment the lock count and return true as well. I wrote the
pseudoLockFile() code to behave this way, but after comparing the results
with the real API calls, I learned that my assumptions were wrong. The 2nd
call returns "false" -- which made much more sense after I looked at it
carefully. If two threads tried to lock the same byte on the same file
handle, both threads would think they succeeded -- which of course is a
dangerous assumption.
So I stripped that "feature" out of the pseudo lock code, and now the pseudo
locks behave identically to the real API calls with respect to the way
SQLite makes use of them.
Robert
