--- Joe Wilson <[EMAIL PROTECTED]> wrote: > Let's assume that for a given OS that fcntl() file locks > work perfectly well on any thread. Would it then be safe > from an SQLite perspective to finalize statements that were > prepared in one thread in a different thread? (where the sqlite > connection would only be used on one thread at a time).
s/prepared/last stepped/ Please let me restate the question. Is fcntl()'s reliability from any thread the sole issue preventing transferring sqlite database connections between threads? > --- [EMAIL PROTECTED] wrote: > > It is possible to construct a case where finalizing a statement > > from a different thread that the one where it was last stepped > > would cause a problem. > > > > Remember, that the operating system bug that is causing all the > > multithreading grief is that file locks created by one thread > > cannot be reliably removed or modified by a different thread. > > So if a statement acquires a lock on the database file in one > > thread and you try to finalize the statement in a different > > thread, the finalization would involve releasing the lock in > > a different thread from which it was acquired - an operation > > that silently fails on certain Linux kernels. > > > > On the other hand, if you sqlite3_reset() all statements in > > the thread where they were last run, then all locks are released > > by the reset. Then you are free to finialize the statements > > from any thread you want. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
