Idea for removing the GIL...

[John Nagle]

On 2/8/2011 1:39 AM, Vishal wrote:
> Hello,
>
> This might sound crazy..and dont know if its even possible, but...
>
> Is it possible that the Python process, creates copies of the
> interpreter for each thread that is launched, and some how the thread
> is bound to its own interpreter ?
>
> This will increase the python process size...for sure, however data
> sharing will remain just like it is in threads.
>
> and it "may" also allow the two threads to run in parallel, assuming
> the processors of today can send independent instructions from the
> same process to multiple cores?

    Won't work.  You'd have two threads updating the same shared data
structures without locking.  In CPython, there's a reference count
shared across threads, but no locking at the object level.

    The real reason for the GIL, though, is to support dynamic
code modification in multi-thread progrems.  It's the ability
to replace a function while it's being executed in another thread
that's hard to do without a global lock.  If it were just a data-side
problem, local object locks, a lock at the allocator, and a
concurrent garbage collector would work.

				John Nagle