global interpreter lock

[Mike Meyer]

Bryan Olson <fakeaddress at nowhere.org> writes:
> Mike Meyer wrote:
>  > Bryan Olson writes:
>  >>Mike Meyer wrote:
>  >> > The rule I follow in choosing my tools is "Use the least complex tool
>  >> > that will get the job done."
>  >>Even if a more complex tool could do the job better?
>  > In that case, the simpler model isn't necessarily getting the job
>  > done. I purposely didn't refine the word "job" just so this would be
>  > the case.
> I didn't ask about any particular case. You stated a general
> rule you follow, and I think that rule is nuts.

You're entitled to write code as complex and unmanagable as you
wish. Me, I'll stick with the simplest thing that solve the problem.

>  >>Now I've gotten off-topic. Threads are winning, and the industry
>  >>is going to multiple processors even for PC-class machines.
>  >>Might as well learn to use that power.
>  > I own too many orphans to ever confuse popularity with technical
>  > superiority.
> The issue here is whether to confuse reality with what one might
> wish reality to be.

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.

>  > I've learned how to use threads, and done some
>  > non-trivial thread proramming, and hope to never repeat that
>  > experience. It was the second most difficult programming task I've
>  > ever attempted(*).
> Great -- lets see it!  Can you point out what parts were so
> hard? How would you have solved the same problems without
> threads?

Google for "aws amiga web server". Somebody is liable to still have
the source around. The hard part was dealing with the making sure that
every sequence of operations that actually happened was correct, of
course. The web server I wrote after that used async i/o, thus
avoiding the problem completely.

>  > As I said above, the real problem isn't threads per
>  > se, it's that the model for programming them in popular languages is
>  > still primitive. So far, to achieve the non-repitition goal, I've used
>  > async I/O, restricted my use of real threads in popular languages to
>  > trivial cases, and started using servers so someone else gets tod eal
>  > with these issues.
> Then maybe we should listen to those other people.

Yes, we probably should. I do. The problem is, the designers of
popular languages apparently don't, so I'm stuck with lousy tools like
thread libraries (meaning you get no compile-time help in avoiding the
problems that plague concurrent programs) and Java's pseudo-monitors.

> Is there a successful single-line-of-execution async-I/O based
> server that provides a service as sophisticated as the modern
> relational- database engines? Why do you think that is?

I don't know - is there? There have certainly been some sophisticated
network servers using async I/O and a single thread of execution. Are
they as sophisticated as a modern relational database? I dunno. Then
again, I already know that async i/o with a single thread of execution
isn't as powerful as threads, so there are almost certainly problem
areas where it isn't suitable and threads are. So what? That doesn't
make the async I/O model any less useful. Of course, if you're only
able to learn one tool, you should probably learn the most powerful
one you can. But just because you only know how to use a hammer
doesn't automatically make everything you encounter a nail.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.