Tim Roberts wrote:
>>> PyGILState_STATE gil = PyGILState_Ensure();
>>> result = PyEval_CallObject(my_callback, arglist);
>>> PyGILState_Release(gil);
>>> Py_DECREF(arglist);
>>> Py_DECREF(result);
> If someone else holds a reference to "argl
Scott David Daniels <[EMAIL PROTECTED]> wrote:
>Francois De Serres wrote:
>>PyGILState_STATE gil = PyGILState_Ensure();
>>result = PyEval_CallObject(my_callback, arglist);
>>PyGILState_Release(gil);
>>Py_DECREF(arglist);
>>Py_DECREF(re
Francois De Serres wrote:
>PyGILState_STATE gil = PyGILState_Ensure();
>result = PyEval_CallObject(my_callback, arglist);
>PyGILState_Release(gil);
>Py_DECREF(arglist);
>Py_DECREF(result);
I think this should be:
PyGILState_S
Christopher Subich wrote:
>Francois De Serres wrote:
>
>
>>- so, on callback, I create a new thread, after checking that the
>>previous one has returned already (WaitOnSingleObject(mythread)) so we
>>only have one thread involved.
>>
>>
>
>Uh... to me, this looks like a frighteningly ineff
Francois De Serres wrote:
> - so, on callback, I create a new thread, after checking that the
> previous one has returned already (WaitOnSingleObject(mythread)) so we
> only have one thread involved.
Uh... to me, this looks like a frighteningly inefficient way of doing
things. How about using
Hiho,
could somebody please enlighten me about the mechanics of C callbacks to
Python? My domain is more specifically callbacks from the win32 API, but
I'm not sure that's where the problem lies. Here's a description...
I want a callback-based MIDI input/processing, so PortMidi was not an
alte
