Re: [sqlite] Share an sqlite3 struct between multiple threads
On Thu, 13 Oct 2005, Florian Weimer wrote: >* Christian Smith: > >> IMHO, SQLite should, however, only open a single file per database (based >> on inode) which should allow threads to override each others locks as the >> locks will be on a single file. > >I think you need multiple file descriptors, otherwise you'd have to >use pread for accessing pages (or wrap each lseek/read call in a >mutex). It's locks on multiple file descriptors to the same file that is causing the problem. Using pread or locked lseek/read should be satisfactory. So long as we retain the semantics of the current OsFile* methods, we should be dandy. > >Apart from that, some kind of per-process table which stores the >device/inode pair and the lock status information should do the trick. >The sqlite3 struct would contain an index into that table. Each time >a file lock has to be changed, the thread acquires a global mutex, and >updates the information in the global lock table. If necessary, POSIX >file locks are acquired or released. We already have an abstract pointer, the OsFile*. The sqlite3 structure should require no changes. OsFile can contain all the required references to actual file descriptors and locking. > >Of course, you can no longer access the same SQLite3 database using >two sqlite3 objects in the same thread without risking a deadlock, but >I don't think this is a major problem. > There should be no problem assuming the OsFile semantics don't appear to change. Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] Share an sqlite3 struct between multiple threads
* Christian Smith: > IMHO, SQLite should, however, only open a single file per database (based > on inode) which should allow threads to override each others locks as the > locks will be on a single file. I think you need multiple file descriptors, otherwise you'd have to use pread for accessing pages (or wrap each lseek/read call in a mutex). Apart from that, some kind of per-process table which stores the device/inode pair and the lock status information should do the trick. The sqlite3 struct would contain an index into that table. Each time a file lock has to be changed, the thread acquires a global mutex, and updates the information in the global lock table. If necessary, POSIX file locks are acquired or released. Of course, you can no longer access the same SQLite3 database using two sqlite3 objects in the same thread without risking a deadlock, but I don't think this is a major problem.
Re: [sqlite] Share an sqlite3 struct between multiple threads
On Wed, 21 Sep 2005, Guillaume Fougnies wrote: >So SQLite is not "portable" on some Unix (more precisely on >recent linux NPTL where file locks seems broken). SQLite is indeed portable. It works round lock problems as best it can with the current model. It is the POSIX locking implementations that are not portable. IMHO, SQLite should, however, only open a single file per database (based on inode) which should allow threads to override each others locks as the locks will be on a single file. Hey, if I have the time, I might have a crack at it. But I've said things like this before, so don't hold your breath. > >i submitted a patch this month: >http://www.sqlite.org/cvstrac/tktview?tn=1417 > >Best regards, > >Wed, Sep 21, 2005 at 02:56:48PM +0100: Christian Smith wrote: >> On Tue, 20 Sep 2005, Marco Bambini wrote: >> >> >I know based on http://www.sqlite.org/faq.html#q8 that it is not safe >> >to share the same sqlite3 structure between multiple threads. >> >But what if I protect its access with a mutex? >> >It is safe? >> >> >> Until recently, by chance, yes, on some platforms. Recent versions of >> SQLite explicitly disallow it and return an error if tried. >> >> Christian > >-- >Guillaume FOUGNIES >Eulerian Technologies > -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
Re: [sqlite] Share an sqlite3 struct between multiple threads
So SQLite is not "portable" on some Unix (more precisely on recent linux NPTL where file locks seems broken). i submitted a patch this month: http://www.sqlite.org/cvstrac/tktview?tn=1417 Best regards, Wed, Sep 21, 2005 at 02:56:48PM +0100: Christian Smith wrote: > On Tue, 20 Sep 2005, Marco Bambini wrote: > > >I know based on http://www.sqlite.org/faq.html#q8 that it is not safe > >to share the same sqlite3 structure between multiple threads. > >But what if I protect its access with a mutex? > >It is safe? > > > Until recently, by chance, yes, on some platforms. Recent versions of > SQLite explicitly disallow it and return an error if tried. > > Christian -- Guillaume FOUGNIES Eulerian Technologies
Re: [sqlite] Share an sqlite3 struct between multiple threads
On Tue, 20 Sep 2005, Marco Bambini wrote: >I know based on http://www.sqlite.org/faq.html#q8 that it is not safe >to share the same sqlite3 structure between multiple threads. >But what if I protect its access with a mutex? >It is safe? Until recently, by chance, yes, on some platforms. Recent versions of SQLite explicitly disallow it and return an error if tried. Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \
[sqlite] Share an sqlite3 struct between multiple threads
I know based on http://www.sqlite.org/faq.html#q8 that it is not safe to share the same sqlite3 structure between multiple threads. But what if I protect its access with a mutex? It is safe? --- Marco Bambini
