Dave, The os_unix.c locking code is extremely convoluted because of the rather insane Posix locking semantics, which tend to make writing threaded code excessively complicated, e.g. if two threads are accessing the same file and one thread closes its file handle the other thread loses all its locks.
I don't know anything about AmigaOS, but if two threads can open the same file using two file handles, and can independently lock and unlock ranges in the file then I'd take a closer look at os_win.c to determine the logic. The semantics are not all that hard. For Windows there are two case: o Pre-NT locks: you can only have write locks o NT and later: you can have read and write locks Sqlite implements a randomized method of simulating read locks for Pre-NT operating systems (Win95/Win98/WinME). It's explained well in os_win.c An explanation on how AmigaOS locking works would be useful. Gé David Pitcher wrote: > there > > Ive just recently ported ( in the nastiest dirtiest way so far ) sqlite onto > another platform - that is AmigaOS version 4.0 ( > powerpc > ):http://www.os4depot.net/index.php?function=showfile&file=library/misc/sqlite3.tar.gz > > However I had to put a health warning on it because in order to get it to > work in the limited spare time I have had so far I had to remove all the > locking code in os_amiga.c ( ripped straight from the os_unix.c file with a > few changes to stop a few clashes in naming of #defined' variables with OS > provided ones ) else any operation would just fail saying the database was > locked ( which yes probably is something wrong in the C runtime library > emulation ). > > So in order to restore sane locking I wrote an AmigaOS specific version of > the os_amiga.c file, but using the Operating System locks built in. Now > looking at the windows implementation it does seem to call operating system > methods for locking files exclusive or shared, but specifically on a section > of the file. The claim that it works over a networked drive has made me > start to think that operating system specific locking mechanisms are totally > the wrong way to go, and that I have misunderstood the code. > > Excuse me if this sounds terribly 'newbie'. > > So, a question, should I NOT be using operating system specific locks ( > indeed my attempts to get it to work once I used OS functions to lock the > file failed to work in a sqlite friendly way ) and instead be just setting > various offsets in the file to certain bitpatterns to indicate to potential > sharers what the state is? My implementation is the only one that attempts > to store a lock descriptor in struct OsFile also. > > I have the feeling Ive missed a porting document or something. Anybody can > set me straight as to whether or not I should be modifying byte offsets in > the file, using OS provided locking systems ( and their semantics ) or > should I just sit down with a pen, ignore the calls to the Windows API in > the win32 one and try and work it out from the unix implementation? > > Regards > > Dave. >
