Paul Rubin <http://[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (phil hunt) writes: >> >Let's see. Reality is that writing correct programs is hard. Writing >> >correct programs that use concurrency is even harder, because of the >> >exponential explosion of the order that operations can happen >> >in. Personally, I'm willing to use anything I can find that makes >> >those tasks easier. >> Indeed so. Use threading (or whatever) when one has to, use an >> asynchronous single-threaded process whenever you can. > This is silly. You could say the exact same thing about if > statements. The number of paths through the program is exponential in > the number of if statements executed. So we better get rid of if > statements. The number of paths through a program isn't exponential in the number of if statements, it's multiplicative. Each if statement multiplies the number of paths through the program by 2, no matter how many other statements you have. On the other hand, with threads, the number of possible execution orders is the number of threads raised to the power of the number of instructions (assuming that instructions are atomic, which is probably false) in the shared code segment. It's a *much* nastier problem. > Really, the essence of programming is to find ways of organizing the > program to stay reliable and maintainable in the face of that > combinatorial explosion. That means facing the problem and finding > solutions, not running away. The principle is no different for > threads than it is for if statements. Correct. But choosing to use a tool that has a less complex model but solves the problem is *not* running away. If it were, you'd have to call using if statements rather than a goto running away, because that's that's exactly what you're doing. I do agree that we should face the problems and look for solutions, because some problems can't be solved with async I/O. That's why I posted the article titled "Static vs. dynamic checking for support of concurrent programming" - I'm trying to find out if one potential solution could be adapted for Python. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list