Feature Request: Py_NewInterpreter to create separate GIL (branch)

[Andre Meyer]

Hi all

Strange enough, there does not even seem to be interest in removing the GIL
in Python 3000.

For some interesting answers on this topic you may read through the thread
"Kill GIL" on the py3k mailing list archives:
<http://mail.python.org/pipermail/python-3000/2006-September/thread.html>.

kind regards
André


On 11/3/06, robert <no-spam at no-spam-no-spam.invalid> wrote:
>
> Feature Request: Py_NewInterpreter to create separate GIL (branch)
>
> Daniel Dittmar wrote:
> > robert wrote:
> >> I'd like to use multiple CPU cores for selected time consuming Python
> >> computations (incl. numpy/scipy) in a frictionless manner.
> >>
> >> Interprocess communication is tedious and out of question, so I
> >> thought about simply using a more Python interpreter instances
> >> (Py_NewInterpreter) with extra GIL in the same process.
> >
> > If I understand Python/ceval.c, the GIL is really global, not specific
> > to an interpreter instance:
> > static PyThread_type_lock interpreter_lock = 0; /* This is the GIL */
> >
>
> Thats the show stopper as of now.
> There are only a handfull funcs in ceval.c to use that very global lock.
> The rest uses that funcs around thread states.
>
> Would it be a possibilty in next Python to have the lock separate for each
> Interpreter instance.
> Thus: have *interpreter_lock separate in each PyThreadState instance and
> only threads of same Interpreter have same GIL?
> Separation between Interpreters seems to be enough. The Interpreter runs
> mainly on the stack. Possibly only very few global C-level resources would
> require individual extra locks.
>
> Sooner or later Python will have to answer the multi-processor question.
> A per-interpreter GIL and a nice module for tunneling Python-Objects
> directly between Interpreters inside one process might be the answer at the
> right border-line ? Existing extension code base would remain compatible, as
> far as there is already decent locking on module globals, which is the the
> usual case.
>
> Robert
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Dr. Andre P. Meyer                        http://python.openspace.nl/meyer
TNO Defence, Security and Safety          http://www.tno.nl/
Delft Cooperation on Intelligent Systems  http://www.decis.nl/

Ah, this is obviously some strange usage of the word 'safe' that I wasn't
previously aware of. - Douglas Adams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20061103/5a61a2f7/attachment.html>