Prev: Ancient C string conventions
Next: Ignorance and Google Groups (again)
From: Paul on 30 Jun 2010 15:28
I have a problem with threading using the Python/C API. I have an
extension that implements a timer, and the C++ timer callback function
calls a Python function. The relevant code looks like this:

static PyObject *timer_setmodname( PyObject *pSelf, PyObject *pArgs )
{

char *b;
PyArg_ParseTuple( pArgs, "s", &b );
mod = PyImport_ImportModule(b);
if( mod == NULL )
{
printf("Could not import %s\n",b);
return Py_None;
}
modsetFlag = TRUE;
return Py_None;
}

static PyObject *timer_setprocname( PyObject *pSelf, PyObject *pArgs )
{
char *b;
if( !modsetFlag )return Py_None;
PyArg_ParseTuple( pArgs, "s", &b );
attr = PyObject_GetAttrString(mod,b);
if( attr == NULL )
{
printf("Could not import %s\n",b);
return Py_None;
}
attrsetFlag = TRUE;
return Py_None;
}

static void CALLBACK PeriodicTimer(UINT wTimerID, UINT msg,
DWORD dwUser, DWORD dw1, DWORD dw2)
{
PyGILState_STATE pgs;

pgs = PyGILState_Ensure();
if(attrsetFlag)
{
pres = PyObject_CallFunction(attr,NULL);
if( pres == NULL )printf("CallFunction failed!\n");
}
PyGILState_Release( pgs );

}

The Python code that sets this up looks like this:

fetimer.setmodname("Timeslice3")
fetimer.setprocname("Timetester")
print "\n Program Waiting for Time Slice"
while True:
time.sleep(0.010)


and the module Timeslice3.py looks like this:

#Timeslice3.py
def Timetester():
pass

When I run this stuff, it works fine for hundreds, often even
thousands, of timer ticks (I've been testing with about thirty ticks
per second, but it doesn't matter - it still crashes at ten or fewer
ticks per second). Sometimes it runs for only a few seconds, sometimes
for ten minutes or so. But it always eventually crashes Python.
Usually it gives no error message. Sometimes, though, it does give an
error message, but not always the same one. I've noted three that it
has given in my testing so far:

Fatal Python Error: This thread state must be current when releasing

Fatal Python Error: PyThreadState_DeleteCurrent: no current tstate

Fatal Python Error: PyEval_SaveThread: NULL tstate

Can anybody help me make this code stable, so that it works all the
time? I'm using Python 2.6.5 under Windows Vista, but it crashes under
Windows XP as well.

From: Thomas Jollans on 1 Jul 2010 13:23
On 06/30/2010 09:28 PM, Paul(a)mail.python.org wrote:
> I have a problem with threading using the Python/C API. I have an
> extension that implements a timer, and the C++ timer callback function
> calls a Python function. The relevant code looks like this:
>
> [snip]
>
> static void CALLBACK PeriodicTimer(UINT wTimerID, UINT msg,
> DWORD dwUser, DWORD dw1, DWORD dw2)

This looks frightfully WIN32. How are you calling a timer? I'm guessing
you're using some win32 function. So my tentative tip on where the
problem might lie is the interaction of Python's PyThreads and the win32
threading primitives you're probably calling.

> {
> PyGILState_STATE pgs;
>
> pgs = PyGILState_Ensure();
> if(attrsetFlag)
> {
> pres = PyObject_CallFunction(attr,NULL);
> if( pres == NULL )printf("CallFunction failed!\n");
> }
> PyGILState_Release( pgs );
>
> }
>
> The Python code that sets this up looks like this:
>
> fetimer.setmodname("Timeslice3")
> fetimer.setprocname("Timetester")

I'm sure this isn't the problem, but why aren't you just passing in an
object? As in fetimer.setcallable(Timeslice3.Timetester)?

> [ snip ]
>
> Fatal Python Error: This thread state must be current when releasing
>
> Fatal Python Error: PyThreadState_DeleteCurrent: no current tstate
>
> Fatal Python Error: PyEval_SaveThread: NULL tstate

As I said, I'd expect there to be some irregularities between what
PyThreads would normally do and what you're doing in the code you didn't
post.

>
> Can anybody help me make this code stable, so that it works all the
> time?

I can't really help you - I have limited experience with the C API, let
alone Python/C threading, and know next to nothing about Windows
programming. Maybe you should ask in a more specialized (and quieter)
forum, such as the CAPI-SIG mailing list, or python-win32.

-- Thomas
From: Paul on 1 Jul 2010 18:00
Thanks, Thomas. The answer to most of your questions is that I'm very
new at this!

I'm asking this on the forums you suggested.

- Paul

On Thu, 01 Jul 2010 19:23:53 +0200, Thomas Jollans
<thomas(a)jollans.com> wrote:

>On 06/30/2010 09:28 PM, Paul(a)mail.python.org wrote:
>> I have a problem with threading using the Python/C API. I have an
>> extension that implements a timer, and the C++ timer callback function
>> calls a Python function. The relevant code looks like this:
>>
>> [snip]
>>
>> static void CALLBACK PeriodicTimer(UINT wTimerID, UINT msg,
>> DWORD dwUser, DWORD dw1, DWORD dw2)
>
>This looks frightfully WIN32. How are you calling a timer? I'm guessing
>you're using some win32 function. So my tentative tip on where the
>problem might lie is the interaction of Python's PyThreads and the win32
>threading primitives you're probably calling.
>
>> {
>> PyGILState_STATE pgs;
>>
>> pgs = PyGILState_Ensure();
>> if(attrsetFlag)
>> {
>> pres = PyObject_CallFunction(attr,NULL);
>> if( pres == NULL )printf("CallFunction failed!\n");
>> }
>> PyGILState_Release( pgs );
>>
>> }
>>
>> The Python code that sets this up looks like this:
>>
>> fetimer.setmodname("Timeslice3")
>> fetimer.setprocname("Timetester")
>
>I'm sure this isn't the problem, but why aren't you just passing in an
>object? As in fetimer.setcallable(Timeslice3.Timetester)?
>
>> [ snip ]
>>
>> Fatal Python Error: This thread state must be current when releasing
>>
>> Fatal Python Error: PyThreadState_DeleteCurrent: no current tstate
>>
>> Fatal Python Error: PyEval_SaveThread: NULL tstate
>
>As I said, I'd expect there to be some irregularities between what
>PyThreads would normally do and what you're doing in the code you didn't
>post.
>
>>
>> Can anybody help me make this code stable, so that it works all the
>> time?
>
>I can't really help you - I have limited experience with the C API, let
>alone Python/C threading, and know next to nothing about Windows
>programming. Maybe you should ask in a more specialized (and quieter)
>forum, such as the CAPI-SIG mailing list, or python-win32.
>
>-- Thomas
 | 
Pages: 1
Prev: Ancient C string conventions
Next: Ignorance and Google Groups (again)