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.16:08:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1345565282.5.0.339036185331.issue15751@psf.upfronthosting.co.za>
In-reply-to
Content
Umm, no. The whole point of the GILState API is that you can call it from a thread which knows *nothing* about Python.

It will then use the *process global* state in the pystate.c statics to initialise that thread with a Python thread state. Currently, that thread state will always be for the main Python interpreter for the process.

All Graham wants is an officially supported way to change which interpreter the pystate.c globals reference *without* shutting down and reinitialising Python completely.

There are going to be limitations on how effective this will be - it still won't support *all* extension modules that use the PyGILState APIs. It will, however, support many more of them than the status quo (which is zero, unless you force your WSGI app to use the main interpreter, which has its own problems).

And you absolutely can control when the OS switches threads - controlling that is what synchronisation primitives are *for*.
History
Date User Action Args
2012-08-21 16:08:02ncoghlansetrecipients: + ncoghlan, pitrou, grahamd
2012-08-21 16:08:02ncoghlansetmessageid: <1345565282.5.0.339036185331.issue15751@psf.upfronthosting.co.za>
2012-08-21 16:08:02ncoghlanlinkissue15751 messages
2012-08-21 16:08:01ncoghlancreate