On Thu, Mar 17, 2011 at 7:30 AM, Laura Creighton <l...@openend.se> wrote: > In a message of Thu, 17 Mar 2011 13:18:07 +1100, William ML Leslie writes: >>Where did you want this discussion to go, Laura? It looks like you >>wanted to talk about the specific problems that need to be dealt with >>while removing the GIL, but it seems to have disintegrated into the >>same "concurrency model X is better than concurrency model Y" free for >>all that regularly seems to happen on this list. Regardless of the >>API that runtimes written with the translation toolkit may provide, >>getting rid of the GIL is a precursor to the implementations of most >>of these models. >> >>-- >>William Leslie > > I'm at a Sprint at PyCON, as are many of the people I think would be > best at answering these specific questions. So it is not surprising > that they are not answering them now. I, myself, am personally interested > in finding out how languages I have never looked at do these things, > because I expect it to influence how one gets rid of the GIL. I was > hoping to have an insight as to how one could avoid going the route > of reimplementing fine grained locks everywhere, pervasively, all > through the codebase. But all I am seeing now is more evidence that > this is impossible. > > Laura
I think it would be cool to have something to point people to in the docs, a page describing why pypy has a gil and what would it take to remove it. I would like to see a clear separation on what steps is needed to make RPython threadsafe (ie. fixing gc choosing and implementing a concurrency model) and what would it take to make the pypy-python interpreter not need a gil (choosing a maybe even different concurrency model and memory semantics, etc). -- Leonardo Santagada _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
