Idea for removing the GIL...

[Jean-Paul Calderone]

On Feb 8, 7:34 am, Vishal <vsapr... at gmail.com> wrote:
> On Feb 8, 3:05 pm, Adam Tauno Williams <awill... at whitemice.org> wrote:
>
> > On Tue, 2011-02-08 at 01:39 -0800, Vishal wrote:
> > > 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 ?
> > > 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?
> > > Comments, suggestions, brush offs  are welcome :))
>
> > Yes, it is possible, and done.  See the multiprocessing module.  It
> > works very well.
> > <http://docs.python.org/library/multiprocessing.html>
>
> > It isn't exactly the same as threads, but provides many similar
> > constructs.
>
> Hi,
>
> Pardon me for my ignorance here, but 'multiprocessing' creates actual
> processes using fork() or CreateProcess().
> I was talking of a single process, running multiple instances of the
> interpreter. Each thread, bound with its own interpreter.
> so the GIL wont be an issue anymore...each interpreter has only one
> thing to do, and that one thing holds the lock on its own interpreter.
> Since its still the same process, data sharing should happen just like
> in Threads.

CPython does support multiple interpreters in a single process.
However,
you cannot have your cake and eat it too.  If you create multiple
interpreters,
then why do you think you'll be able to share objects between them for
free?

In what sense would you have *multiple* interpreters in that scenario?

You will need some sort of locking between the interpreters.  Then
you're either
back to the GIL or to some more limited form of sharing - such as you
might
get with the multiprocessing module.

Jean-Paul