--- [EMAIL PROTECTED] wrote: > Joe Wilson <[EMAIL PROTECTED]> wrote: > > --- [EMAIL PROTECTED] wrote: > > > Ran <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > > > > > I *think* that sqlite3_close behave strangly. > > > > > > > > I use version 3.3.7 on Linux (Fedora Core 5). > > > > > > > > What I do is to open a database, and start a transaction in it. Then, > > > > without ending the transaction, open again the database and simply > > > > close it. > > > > > > > > I found out, that the inner sqlite3_close return 0 (SQLITE_OK), but the > > > > file handle is not released. So if I do it too many times, I run out of > > > > file > > > > handles. > > > > > > > > > > This behavior is intentional. It is a work-around for a bug > > > > SQLite should find the inode of the database file via stat()'s st_ino > > field prior to open() and if it is the same as an already opened > > database file, it should use the same (refcounted) file descriptor, > > eliminating the need for open() in this case. > > > > That would only work in a single-threaded application. > Imagine the trouble that would ensue if two different > threads tried to seek to different places and read, at > the same time, on the same file descriptor.
Yes, I also realized that about 30 seconds after I sent the email. > One solution that might work, however, it to satisfy new > open requests with file descriptors that are in the queue > of file descriptors that are waiting to be closed. Assuming they stat() to the same inode, sure. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
