Hi Kees Thanks for the response and giving me a clue to look at dot locking, I had missed the dot lock mechanism as I had concentrated mainly on the osWin.c file. I cant find any documentation other than the source code on how this low level file locking stuff is implemented.
I am currently reading through the code to see if I can figure it out. The unix.c module is horrendously complicated so I am struggling to make sense of it. In simple terms I was thinking that when the db file is opened for writing, I could use the filename with ".lock" appended, and open that new dummy file, which is then used to determine if I have a lock on the original database file or not ? As the code says for dot locking there is really only a 2 state lock, exclusive or no lock. I got lost by the complexity of the code, for vxworks it seems to keep linked lists of filenames, not sure why I would need to do that, also it does lots of other stuff that I didnt really understand for example updating the file timestamp on the ".lock" file. I was hoping Dr Hipp could manage to find a few minutes to write some notes explaining what needs to be implemented re: dot locking and what can be simplified and ignored. Thanks if anyone can fill in some details here. Geoff Kees Nuyt wrote: > > On Fri, 12 Mar 2010 02:22:31 -0800 (PST), GeoffW > <geoffw...@hotmail.com> wrote: > >> >>Hi >> >>Now I have got a half ported version of Sqlite up and running on MQX I cant >>put off any longer the question of file locking and how I tackle that ? For >>the moment i had made the xLock() and xUnlock() the same as in osWin.c >>version but with the Windows lock() and unlock() function calls commented >>out. >> >>The problem I have is that MQX's file system is just ANSI C, and it lacks >>any lock/unlock functions. >> >>As Sqlite has been ported to so many diverse operating systems I am hoping >>that this question of what to do for an ANSI only File system has already >>been hit and a workaround defined ? >> >>I am pretty hazy on this topic of file locking so I would appreciate some >>basic discussion and guidance. It might help if I explain my application a >>little. It is an embedded system where we are just running one application, >>but it is multithreaded. For my initial porting work I have made >>SQLITE_THREADSAFE = 0 (so I probably dont even need a file lock in the >>configuration I have at present ?) >>However I would of course like to make SQLITE_THREADSAFE = 1 so that >>multiple tasks can safely access a database. > > (Disclaimer: this is not my specialism, I hope it helps > nevertheless) > > SQLITE_THREADSAFE has effect on threads within the same > process (=task), especially when they use the same > connection. You need file locks for synchronisation between > different processes. If the filesystem doesn't provide them, > you could use the dot lockfile paradigm, which seems to be > associated with SQLITE_ENABLE_LOCKING_STYLE. > >>Thanks for any guidance >> >>Regards Geoff > -- > ( Kees Nuyt > ) > c[_] > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://old.nabble.com/Porting-Sqlite-to-MQX-OS%3A-Question-2-tp27874124p27905578.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
