For the record, this problem went away when I upgraded to the latest & greatest (3.7.15.2). ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Dan Kennedy [danielk1...@gmail.com] Sent: Tuesday, February 26, 2013 10:32 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] locked database returning SQLITE_IOERR, not SQLITE_BUSY
On 02/27/2013 12:49 AM, Greg Janée wrote: > I've instrumented the SQLite source and have found that the error is > occurring at the fcntl call near the end of function unixLock (in SQLite > version 3.7.0.1, this is line 23592 of sqlite3.c). The relevant code > snippet is below. fnctl is returning -1, and errno=2 (ENOENT). From my > reading of the fcntl man page, it wouldn't seem to be possible for fcntl > to even return ENOENT. > > SQLite is being used from a multi-threaded application in my case, and I > don't know if it's a possibility that some other thread is overwriting > errno. But then, if that's even a possibility, wouldn't that seem to > preclude using SQLite in a multithreaded application at all? I think errno is thread specific on any unix that isn't ancient. On Solaris you have to get the compiler flags right - "-D_REENTRANT" or something. Maybe "-mt" too. I thought you might have been reading errno fter the sqlite3_step() call returned. It is weird that it is setting errno to ENOENT... _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
