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. 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. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
