Nick Craig-Wood wrote: > Splitting the GIL introduces performance and memory penalties.... > However its crystal clear now the future is SMP. Modern chips seem to > have hit the GHz barrier, and now the easy meat for the processor > designers is to multiply silicon and make multiple thread / core > processors all in a single chip. > So, I believe Python has got to address the GIL, and soon. However, there is no reason to assume that those multiple cores must work in the same process. One of the biggest issues in running python in multiple simultaneously active threads is that the Python opcodes themselves are no longer indivisible. Making a higher level language that allows updates work with multiple threads involves lots of coordination between threads simply to know when data structures are correct and when they are in transition.
Even processes sharing some memory (in a "raw binary memory" style) are easier to write and test. You'd lose too much processor to coordination effort which was likely unnecessary. The simplest example I can think of is decrementing a reference count. Only one thread can be allowed to DECREF at any given time for fear of leaking memory, even though it will most often turn out the objects being DECREF'ed by distinct threads are themselves distinct. In short, two Python threads running simultaneously cannot trust that any basic Python data structures they access are in a consistent state without some form of coordination. --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
