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 ncoghlan
Recipients grahamd, ncoghlan, pitrou
Date 2012-08-21.14:06:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1345557968.83.0.983343835339.issue15751@psf.upfronthosting.co.za>
In-reply-to
Content
Just as they do today, all externally created threads will still go to *one* interpreter when they hit PyGILState_Ensure(). It's just that interpreter won't be the main one.

Since the whole point of the PyGILState API is to support threads that don't have a previously created thread state, there's no getting around the requirement to have a single blessed interpreter that handles all externally created threads in a given process.

It will be up to mod_wsgi (and any other embedding application that uses the new function) to make sure it calls this at a time when there aren't any existing calls to PyGILState that would be disrupted. (Assuming we can't figure out a locking scheme that *ensures* no such threads are running when the switch occurs)
History
Date User Action Args
2012-08-21 14:06:09ncoghlansetrecipients: + ncoghlan, pitrou, grahamd
2012-08-21 14:06:08ncoghlansetmessageid: <1345557968.83.0.983343835339.issue15751@psf.upfronthosting.co.za>
2012-08-21 14:06:08ncoghlanlinkissue15751 messages
2012-08-21 14:06:07ncoghlancreate