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.
* 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). -----Original Message----- From: Robert Simpson [mailto:[EMAIL PROTECTED] Sent: Saturday, January 07, 2006 5:49 PM To: sqlite-users@sqlite.org Subject: [sqlite] CE locking -- review the code Attached is a pseudo-locking mechanism I wrote, intending to use it for Windows CE. The design goal for the code was to allow the existing os_win.c locking code to remain intact with zero replacement coding involved. With that in mind, I basically implemented LockFile(), LockFileEx() and UnlockFile() using a mutex and some shared global memory. It is similar in nature to Nuno Lucas's "idea" behind locking -- however, its completely re-realized in this code. The code is designed around SQLite's behavioral use of those API functions and for testing purposes, does not require Windows CE to run and test. Please have a look at it and poke some holes in it. Robert To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
