On Wed, Nov 24, 2010 at 02:01:40PM +0200, Gabor Szabo wrote: > The other day I was at a client that uses Perl in part of their system and we > talked a bit about the language and how we try to promote it at various > events. > > Their "Perl person" then told me he would not use Perl now for a large > application because: > > 1) Threads do not work well - they are better in Python and in Java.
Python? Really. The language with a global interpreter lock, and massive contention if you try to run compute threads on a multicore machine? [Note, that statement is deduced from what credible Python people present at conferences, not actual experience. See http://www.dabeaz.com/GIL/ I suspect that Python is *way* better at spawning new threads cheaply, and at running multiple concurrent non-compute threads.] Now, this may mean that Python fits his threading needs better than ithreads, but I wouldn't advice that Perl 5 adopts Python's threading approach, because it's not a good-enough general solution. I'm not convinced that there even *is* a good way to do "it" in a dynamic language implemented in C (where "it" is creating the behaviour of "traditional" POSIX threads, with cheap thread creation, relatively cheap cross-thread communication, use of more than one core, and no SEGVs.) [Python has a GIL. Unladen Swallow failed to remove it. So internally it is single threaded. Ruby has green threads. So one core only. I don't know about PHP, but I'm not convinced that I trust the quality of its C implementation in the general case] The underlying problems in Perl are that: 1: any Perl-space read can be a write underneath, as variables mutate to cache string or numeric values. Which effectively means that you need to take out a write lock on every read. Which is "spendy". 2: C extensions access Perl's variables by direct structure manipulation, rather than calling C functions. Which means that you can't (really) intercept (logical) accesses to variables to indirect them via thread-safe(r) code. Nicholas Clark
