global interpreter lock

[Mike Meyer]

Bryan Olson <fakeaddress at nowhere.org> 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.