Antoine Pitrou <pit...@free.fr> added the comment: > 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? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10915> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
