On Tue, 2005-07-26 at 23:20 -0400, Kervin L. Pierre wrote: > We get all those threads related questions because SQLite > is difficult to use with threads and has sparse sometimes > conflicting documentation on the subject.
Maybe people think that SQLite should serialize its own internals. Maybe that's why people keep saying this. It shouldn't. Those serialization steps are expensive and not always necessary. A programmer using thread-think should be able to create the appropriate locks WHEN appropriate- e.g. a "gui application with an SQLite worker thread" won't need any locks on sqlite's data structures because only one thread will be accessing them. meanwhile, two threads attempting to multiplex access to a single sqlite handle are a) bound to be confused, and b) need those resource locks anyway. > Don't get me wrong, again I am not complaining, it is *way* > better than the other options out there. But you can't > expect someone to magically figure out an API based on > one or two sentence definitions and comments in a header > file without asking a few questions and making a few > mistakes. I _NEVER_ said that I expect people to figure out an API through magical means. I _would_ however expect people trying to use a third-party library to already have isolated their problem _to_ that third party library. I resent people saying: "I'm writing a program using threads and SQLite doesn't work with it," when what they should be saying is "I don't know how to use threads."
