> Of course, I wasted 4 hours tracking the problem down..... This is > yet another episode that demonstrates how threads are a pernicious > evil that should be studiously avoided in any program that you > actually want to work. Threads cause hard-to-trace bugs. Threads > result in non-deterministic behavior. Threads make programs run > slower. Just say "No" to threads...
Let me start by saying that I have a great respect for SQLite and its developers. I'm extremely pleased with the code itself as well as with the great support community. :) However, I'm a bit surprised by the "threads are evil" mantra. Certainly, threads can cause "hard-to-trace bugs" when used improperly. However the same can be said for many other language constructs, such as pointers, dynamic allocation, goto statements, etc. Any tool can get you into trouble if abused. No matter how you slice it, concurrent programing can be tricky. While multi-thread and multi-process approaches each have pros and cons, the dangers are the same: The programmer must take cautions to ensure that any shared resource is accessed safely. When used properly, either approach can work reliably. I have no doubt that there are many cases where the multi-process approach has clear benefits. Indeed, if one prefers the multi-process approach, then by all means use it. However, a multi-threaded approach can have benefits as well. Advocating a "one size fits all" approach for everyone, without knowing the details of a particular application, just seems an oversimplification to me. Sorry for my rant :) ~Eric _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
