Thanks, John, for your reply. We also had the same idea about wanting to avoid the SQLITE_BUSY possibilities, and just have callers wait.
So, I think if I understand your response correctly, by having THREADSAFE=0 we have effectively commented out any code that would be trying to use fcntrl(), and hence, we should have no problem (from a SQLite point of view) of having multiple threads use the same connection, as long as we are correctly controlling access to this connection with our own mutexes. Is that right? Thanks, Mark > -----Original Message----- > From: John Stanton [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 19, 2007 6:54 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Moving database connections across threads > > > The underlying issue with thread misbehaviour is that POSIX > file locks > are process specific, not thread specific requiring some > tormented logic > . You only need the POSIX locks if you have multiple access > to the same > database and are writing to the database. > > If you have a multi-threaded application and synchronize access using > pthread rwlocks or on Windows read/write locks made from a mutex and > event or semaphore then you can ignore the POSIX locks. If > your traffic > rate is not very high you can just use a mutex around the > Sqlite calls > for synchronization. > > In our threaded applications we use either rwlocks or a mutex > and have > the bonus of not having to add application logic to handle a > BUSY state > and endure busy waits and other polling indignities since the threads > just block when there is contention. > > If you have network connected files (like SMB or NFS) or multiple > processes on one machine you will need the POSIX locks. > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
