Bryan Olson <[EMAIL PROTECTED]> writes: phil hunt wrote: > > What's important is *predictability*, e.g. which instruction will > > the computer execute next? > > > > If you only have one thread, you can tell by looking at the code > > what gets executed next. It's very simple. > Not really. Trivially, an 'if' statement that depends upon input > data is statically predictable. Use of async I/O means makes the > programs execution dependent upon external timing.
Yes, but that depenency is tied to a single point - the select call. The paths after that are statically predictable. This makes the code very managable. > > If you have 2 threads you can easily have a timing-based situation > > that occurs rarely but which causes your program to behave wierdly. > > This sort of bug is very hard to reproduce and therefore to fix. > So we need to learn to avoid it. No, we need tools that make it impossible to write codde that triggers it. Async I/O is one such tool, but it has lots of other limitations that make it unsuitable for many applications. > [...] > > Yes, find solutions. Don't find dangerous dead-ends that look like > > solutions but which will give you lots of trouble. > If concurrency is a dead end, why do the programs that provide > the most sophisticated services of any in the world rely on it > so heavily? I don't know what Phil is saying, but I'm not calling concurrency a dead end. I'm calling the tools available in most programming languages for dealing with it primitive. We need better tools. <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
