On Thu, 2005-07-28 at 08:44 -0400, Eli Burke wrote: > 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.
Like it or not, you still don't have any idea what you are doing. They [threads] are never the only solution, and they are rarely appropriate. I'm certain I'm not being entirely clear on just how rare it is: Threads so rarely help that the programs that they CAN help don't often use them, and the programs that it DOESN'T HELP- nay actually hurts, are the ones using threads. 20 years ago, people said the exact same thing about goto- the places where it can help are in programs that don't often use them, but the places where it DOESN'T HELP- and actually hurts, are the ones using goto. Now, if you're feeling like you're on a high horse, go ahead: point out a single common platform where threads are the necessity. Here's some hints: * it's not windows * it's not unix * it's not java (closures) * it's not lisp (closures) * it's not forth (coroutines) * it's not macos (see unix) * it's not gtk+ (closures/event pump) That said: Writing kernel processes for the linux kernel requires a lot of thread-think in that you have to keep all of your memory access private. I generally suspect, however, that the people having problems with threads _there_ aren't the same people who are having problems with threads _here_. > 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. SQLite doesn't have anything to do with threads. That's the problem. What people miss is that they either think memory-chunk serialization is automatic, or automatically provided by SQLite. But SQLite isn't different from the majority of third-party libraries out there, and if _THIS_ is what is tripping people up, then it should be all the more evident that thread-think makes people dumb. [[ personally: I don't think this is what's tripping people up. _I_ think that they really don't know how to use threads in the first place. ]] > 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. No. In order to use threads with SQLite you need to know how to use threads. In order to use threads with ImageMagick, you need to know how to use threads. In order to use threads with PostgreSQL you need to know how to use threads. In order to use threads with libmodplug you need to know how to use threads. Notice a common theme? All of these libraries require the user do their own serialization, and yet people continue to ask "how do I make OpenLDAP work with threads" when they really mean "how do I use threads." There isn't any grey area here. Threads are complicated- so complicated that they screw up otherwise promising programmers into thinking that they're necessary and/or easy, when they're clearly neither. > 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? I doubt it. It's worth a shot though.
