Hi Jeff, On Wed, Sep 30, 2009 at 11:19:06AM -0700, Jeff Anderson-Lee wrote: > > It's true that we don't have a good story here and we need one. Something > > a'la Jython would work (unlike in CPython), but it's work. > > > The last time I looked, Hoard didn't support x86_64 although it did seem > to work for threaded environments fairly efficiently if I recall. > Having a separate arena for each thread (or each virtual processor) > helps to avoid a lot of locking for frequent/small allocations in a VM. > That may mean factoring out the allocation so that it calls something > like myalloc(pool,size) rather than just malloc(size). I read that pypy > was trying to factor out the GC code to support multiple back-ends. > Having an API that supports multiple concurrent allocator pools can be > useful in that regard.
That's all true, but the primary issue with the GIL in Python (either in CPython or PyPy) is more fundamental. Its purpose is to protect concurrent object accesses. It is to avoid getting random nonsense or crashing the interpreter if you do two lst.append() on the same list in two threads in parallel, for example. The Python language reference itself says that doing this gives you the "expected" result, i.e. the same as if the lst.append() was protected with locking. From there to the GIL the distance is not very large. We could ignore this point and try to implement a free multithreading interpreter in PyPy -- and we would then hit all the issues you describe above, and have to solve them somehow. But the point is that it would no longer be a fully compliant Python interpreter. Depending on the use case it might be either a very useful quasi-Python interpreter, or a useless one that crashes randomly when running any large body of code that otherwise works on CPython or Jython. Of course it's not the end of the story, as shown e.g. by Jython, in which the locking exists too but is more fine-grained. There is one lock per list or dictionary, which itself costs very little because the Java platform is extremely good at optimizing such locks. A bientot, Armin. _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
