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 amaury.forgeotdarc
Recipients amaury.forgeotdarc, anacrolix, docs@python, ncoghlan, nikratio, swapnil, verigak
Date 2010-09-17.20:49:23
SpamBayes Score 7.5416585e-07
Marked as misclassified No
Message-id <1284756565.71.0.0674315477993.issue6627@psf.upfronthosting.co.za>
In-reply-to
Content
> ctypes performs the initializations in a way that break the
> threading.local functionality. 

Not quite. ctypes (or more exactly: the PyGILState_Ensure() and PyGILState_Release() functions, which are the standard API to do this) is in a situation where it must call Python code from a thread which has no PyThreadState.  So it creates a thread state, runs the code, and destroys the thread state; is this wrong?

If you want to keep Python state during your C thread, there are 4 lines to add to your function:

void *async_cb(void *dummy)
{
    PyGILState_STATE gstate = PyGILState_Ensure();
    Py_BEGIN_ALLOW_THREADS
    (*callback_fn)();
    (*callback_fn)();
    Py_END_ALLOW_THREADS
    PyGILState_Release(gstate);
    pthread_exit(NULL);
}
History
Date User Action Args
2010-09-17 20:49:25amaury.forgeotdarcsetrecipients: + amaury.forgeotdarc, ncoghlan, nikratio, verigak, swapnil, anacrolix, docs@python
2010-09-17 20:49:25amaury.forgeotdarcsetmessageid: <1284756565.71.0.0674315477993.issue6627@psf.upfronthosting.co.za>
2010-09-17 20:49:23amaury.forgeotdarclinkissue6627 messages
2010-09-17 20:49:23amaury.forgeotdarccreate