[pypy-dev] Thinking about the GIL

[Leonardo Santagada]

On Thu, Mar 17, 2011 at 7:30 AM, Laura Creighton <lac at 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