Message126349
> 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? |
|
Date |
User |
Action |
Args |
2011-01-15 20:30:34 | pitrou | set | recipients:
+ pitrou, loewis, amaury.forgeotdarc, ncoghlan, grahamd |
2011-01-15 20:30:31 | pitrou | link | issue10915 messages |
2011-01-15 20:30:31 | pitrou | create | |
|