Re: segfault when calling Python from C thread
Travis Berg wrote:
>
> I'm running into a problem when trying to perform a callback to a
> Python function from a C extension. Specifically, the callback is
> being made by a pthread that seems to cause the problem. If I call
> the callback from the parent process, it works fine. The PyObject is
> static, and holds the same value in both Parent and thread, so I'm at
> a loss as to what would be different in the pthread from the parent
> that would cause a segfault on the callback. The machine specifics
> are an x86 intel processor with RedHat linux.
>
>
> /* calling callback */
> void callback(char * str) {
> PyObject *arglist;
> PyObject *result;
> if(str == NULL)
> return;
>
> if(my_callback == NULL) {
> printf("no callback function provided, returning...\n");
> return;
> }
>
> /* Time to call the callback */
> arglist = Py_BuildValue("(s)", str);
> result = PyEval_CallObject(my_callback, arglist);
> Py_DECREF(arglist);
> if(result == NULL)
> return;
> Py_DECREF(result);
> }
Your callback function needs to hold the Python GIL (and have a vaild
threadstate) before it calls any Python C-API functions. Change the
last part of it to:
PyGILState_STATE state;
/* ... */
/* Time to call the callback */
state = PyGILState_Ensure();
arglist = Py_BuildValue("(s)", str);
result = PyEval_CallObject(my_callback, arglist);
Py_DECREF(arglist);
if(result == NULL)
return;
Py_DECREF(result);
PyGILState_Release(state);
}
Also, somewhere in your main thread you should call PyEval_InitThreads
before any of the callback threads execute. (This call is made
automatically if you are creating new threads using Python's thread
module, but if the new threads are created by some C code, you need to
call it yourself.)
---
Greg Chapman
--
http://mail.python.org/mailman/listinfo/python-list
Re: segfault when calling Python from C thread
Fredrik Lundh wrote:
> Greg Chapman wrote:
>
> > Your callback function needs to hold the Python GIL (and have a
> > vaild threadstate) before it calls any Python C-API functions.
> > Change the last part of it to:
> >
> >PyGILState_STATE state;
> >
> >/* ... */
> >
> >/* Time to call the callback */
> >
> >state = PyGILState_Ensure();
> >
> >arglist = Py_BuildValue("(s)", str);
> >result = PyEval_CallObject(my_callback, arglist);
> >Py_DECREF(arglist);
> >if(result == NULL)
> >return;
> >Py_DECREF(result);
> >
> >PyGILState_Release(state);
> > }
>
> you might wish to make sure you release the GIL even if the callback
> raises an exception...
>
>
Argh, thanks for catching that. You probably put that too politely
though (in case anyone sees this who might think that is optional): one
should absolutely make sure all code paths which call PyGILState_Ensure
have a matching call to PyGILState_Release.
---
Greg Chapman
--
http://mail.python.org/mailman/listinfo/python-list
Re: super with only one argument
Steven Bethard wrote: > When would you call super with only one argument? The only examples > I can find of doing this are in the test suite for super. > I think it's to allow something like this: class A(B, C): __super = super(A) def foo(self): return self.__super.foo() This allows you to rename A and only have to change one super call to reflect the new name. --- Greg Chapman -- http://mail.python.org/mailman/listinfo/python-list
Re: super with only one argument
Greg Chapman wrote: > Steven Bethard wrote: > > > When would you call super with only one argument? The only examples > > I can find of doing this are in the test suite for super. > > > > I think it's to allow something like this: > > class A(B, C): > __super = super(A) > def foo(self): > return self.__super.foo() > > This allows you to rename A and only have to change one super call to > reflect the new name. > Except that doesn't work unless you use something like the autosuper metaclass trick from test_descr.py (since the class A does not yet exist where I put that super call). And autosuper has a comment that it "only works for dynamic classes" -- not sure that I understand what "dynamic" means there. In case you haven't guessed by now, I've only used two-arg super in my own code. --- Greg Chapman -- http://mail.python.org/mailman/listinfo/python-list
Re: PythonWin troubleshooting
On 13 Dec 2005 14:27:48 -0800, "chuck" <[EMAIL PROTECTED]> wrote: > >After some use the problems have re-appeared with the "ActivePython >2.3.5.236" distro. I think the problem is related to some sort of >shell hook as it goofs up not only PythonWin, but other windows >applications and windows itself. Can't get the context menu to work in >explorer, the task manager from the task bar, etc. Something is really >goofed up! The problem only appears when PythonWin is running or was >running and is hung in memory from a non-clean PythonWin shutdown. This sounds like you may have a corrupted registry. See this bug report for a description: http://sourceforge.net/tracker/?group_id=78018&atid=551954&func=detail&aid=1017504 There was a fix added for this in one of the recent builds, and I haven't run into it lately, but it appears from one follow-up in the above that the problem can still occur. Anyway, to get rid of the symptoms you need to clean up the "HKCU\Software\Python2.4\Python for Win32" key by getting rid of all the extra toolbar keys (or if you don't have any customizations, you can just delete the above key, and PythonWin will recreate it the next time it is run). I guess there is no guarantee that you will not run into this again, but, as I said, I have not seen it recur with the latest builds of PythonWin. --- Greg Chapman -- http://mail.python.org/mailman/listinfo/python-list
