On May 15, 2009, at 1:21 PM, <logan.rat...@emerson.com> <logan.rat...@emerson.com > wrote:
> I don't know what causes it, but I see the exact same thing running an > embedded 2.6.17 kernel on a PPC architecture. And my application is > decidedly single-threaded. Oddly enough, the exact same application > running on multiple 2.6 kernels running on i86 machines does not show > this behavior. > From a comment in the os_unix.c source file (which implements the SQLite backend for all unix-like systems): ** Yet another problem: LinuxThreads do not play well with posix locks. ** ** Many older versions of linux use the LinuxThreads library which is ** not posix compliant. Under LinuxThreads, a lock created by thread ** A cannot be modified or overridden by a different thread B. ** Only thread A can modify the lock. Locking behavior is correct ** if the appliation uses the newer Native Posix Thread Library (NPTL) ** on linux - with NPTL a lock created by thread A can override locks ** in thread B. But there is no way to know at compile-time which ** threading library is being used. So there is no way to know at ** compile-time whether or not thread A can override locks on thread B. ** We have to do a run-time check to discover the behavior of the ** current process. The run-time check mentioned in the last sentence involves creating a new thread and experimenting to see how it interacts with posix advisory locks. I'm guessing that extra thread is what you are seeing as a second process. One always runs into a bazillion subtle problems like this when you get into threads. I keep trying to tell y'all that threads are evil. I wish you'd listen..... If you recompile SQLite with -DSQLITE_THREADSAFE=0 then all of the above code is omitted and you should not get any extra process table entries. D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
