Mrs. Brisby wrote: > My PII-350 easily handles 2 million local deliveries per hour, and it > fork()s for each one. > > As has been mentioned: If you think threads are going to make your > program fast, you don't know what you're doing.
Like it or not, the world is bigger than just Unix. Some of us have to write code for other platforms, or even cross-platform. You can preach until you turn green about the dangers of threads in the hands of all the rest of us dumb idiots, but that doesn't change the fact that sometimes they are an appropriate (or the only) solution. Mrs. Brisby wrote: > Maybe people think that SQLite should serialize its own internals. Maybe > that's why people keep saying this. [snip] > 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. I don't think anyone is asking for SQLite to be serialized, or for it to work properly when a db handle is reused by multiple threads. Yes, there are a lot of questions about threads on the mailing list. Maybe it is because Kervin Pierre is right-- the documentation RE threads is poor. It's no big secret that Dr. Hipp is in the "threads are bad" camp, and so getting helpful information means spending hours reading through old mailing list posts, sorting through the chaff, trying to figure out what behavior applies to the current software version. (a number of significant threading issues have been resolved since 3.0 was released). There is a short article in the wiki on threads, but you have to know to look for it. Consider the lone FAQ entry on threading. It contains two helpful bits of advice. 1) Don't reuse db handles between threads. 2) Don't reuse db handles after fork(). Now imagine if that information was actually in a useful place, namely in the sqlite3_open API reference. Perhaps that would cut down on some new user confusion? -Eli
