Bryan Olson <[EMAIL PROTECTED]> writes:
> Mike Meyer wrote:
> > The real problem is that the concurrency models available in currently
> > popular languages are still at the "goto" stage of language
> > development. Better models exist, have existed for decades, and are
> > available in a variety of languages.
> That's not "the real problem"; it's a different and arguable
> problem. The GIL isn't even part of Python's threading model;
> it's part of the implementation.
Depends on what point you consider the problem.
> > It's not that these languages are for "thread-phobes", either. They
> > don't lose power any more than Python looses power by not having a
> > goto. They languages haven't taken off for reasons unrelated to the
> > threading model(*).
> > 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.
> 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. 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(*). 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. If I ever find myself having to have non-trivial
threads again, I'll check the state of the threading models in other
languages, and make a serious push for implementing parts of the
program in a less popular language with a less primitive threading
model.
<mike
*) The most difficult task was writing horizontal microcode, which
also had serious concurrency issues in the form of device settling
times. I dealt with that by inventing a programming model that hid
most of the timing details from the programmer. It occasionally lost a
cycle, but the people who used it after me were *very* happy with it
compared to the previous model.
--
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
