This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients amaury.forgeotdarc, grahamd, loewis, ncoghlan, pitrou
Date 2011-01-15.20:30:30
SpamBayes Score 5.2180482e-15
Marked as misclassified No
Message-id <1295123427.3717.14.camel@localhost.localdomain>
In-reply-to <1295122543.7.0.0369609684868.issue10915@psf.upfronthosting.co.za>
Content
> Can you please provide an example of what user would do and what
> changes existing extension modules would need to make?

The patch contains such a change for ctypes. It's quite simple actually.

> By default stuff would work on the main interpreter, but if for a
> specific thread it wanted to operate in context of a different sub
> interpreter, would call PyInterpreterState_Swap() to indicate that.
> That would store in TLS outside of any existing data structures.
> Functions like existing PyGILState_Ensure()/PyGILState_Release() would
> then look up that TLS variable to know which interpreter they are
> working with.

That sounds like an ugly hack to avoid passing the desired interpreter
state directly to PyGILState_Ensure()/PyGILState_Release().

Besides, it will only work if a thread always serves the same
sub-interpreter.

> Doing it this way meant that no C extension modules using
> PyGILState_??? functions would need to change at all, as what
> interpreter is being operated on dictated by who created the thread
> and initiated call in to Python interpreter.

Who would do that, if it's not the extensions in question?
"who created the thread" is often a third-party library (e.g. sqlite)
that has no notion of a Python interpreter. That's the whole point of
using the PyGILState_* API, really. So extensions *will* have to be
fixed.

> That you are saying that sqlite needs changes is what makes me things
> the way you are going is a problem. It isn't practical to make SWIG
> change to use something other than
> PyGILState_Ensure()/PyGILState_Release(), it should be transparent and
> required no changes to existing C extensions.

What does SWIG use them for?
History
Date User Action Args
2011-01-15 20:30:34pitrousetrecipients: + pitrou, loewis, amaury.forgeotdarc, ncoghlan, grahamd
2011-01-15 20:30:31pitroulinkissue10915 messages
2011-01-15 20:30:31pitroucreate