pygtk 和原生 gtk_main();混合

Question

我正在尝试开发一个基于 C 的应用程序，它嵌入了一个或多个 Python 解释器。我在 C 部分使用 gtk-things，并在其中逻辑调用 gtk_main()。

Python 解释器是使用 Py_NewInterpreter() 在单独的 pthread 中创建的，并且基本上永远运行（在脚本终止的情况下会在末尾添加一个“while True”循环）。

现在我想在这些脚本中使用 pyGTK，它似乎可以工作，直到有回调（发出信号）。您可以注册信号处理程序以指向 Python 脚本中的部分 ok，但似乎 gtk 主循环在它们发生时无法正确引导它们，从而导致如下日志所示的段错误。

我猜这可能与未正确初始化 python 线程状态有关，但不确定。有人会知道我做错了什么或要检查什么吗？

#0 0xb7ecfc9a in PyFrame_New () from /usr/lib/libpython2.5.so.1.0 #1 0xb7f376ed in PyEval_EvalCodeEx () from /usr/lib/libpython2.5.so.1.0 #2 0xb7ed09b6 在?? () 来自 /usr/lib/libpython2.5.so.1.0 #3 0xb7eae327 in PyObject_Call() from /usr/lib/libpython2.5.so.1.0 #4 0xb7f30f7c in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.5.so.1.0 #5 0xb7eaeb5c in PyObject_CallObject () from /usr/lib/libpython2.5.so.1.0 #6 0xb424face in ?? () 来自 /usr/lib/pymodules/python2.5/gtk-2.0/gobject/_gobject.so #7 0xb76e113a in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #8 0xb76f761d 在?? () 来自 /usr/lib/libgobject-2.0.so.0 #9 0xb76f8bfc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #10 0xb76f9076 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #11 0xb7ab3a8a in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 #12 0xb7ab5048 在?? () 来自 /usr/lib/libgtk-x11-2.0.so.0 #13 0xb76eecac in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #14 0xb76df7a9 在?? () 来自 /usr/lib/libgobject-2.0.so.0 #15 0xb76e113a in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #16 0xb76f6eba 在 ?? () 来自 /usr/lib/libgobject-2.0.so.0 #17 0xb76f8bfc in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #18 0xb76f9076 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #19 0xb7ab3b2a in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 #20 0xb7ab3b73 在?? () 来自 /usr/lib/libgtk-x11-2.0.so.0 #21 0xb7b70e74 在?? () 来自 /usr/lib/libgtk-x11-2.0.so.0 #22 0xb76df7a9 在?? () 来自 /usr/lib/libgobject-2.0.so.0 #23 0xb76e113a in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #24 0xb76f7266 在?? () 来自 /usr/lib/libgobject-2.0.so.0 #25 0xb76f8a7b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #26 0xb76f9076 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #27 0xb7c9d156 在?? () 来自 /usr/lib/libgtk-x11-2.0.so.0 #28 来自 /usr/lib/libgtk-x11-2.0.so.0 的 gtk_propagate_event () 中的 0xb7b694cd #29 0xb7b6a857 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #30 0xb79f3dda 在?? () 来自 /usr/lib/libgdk-x11-2.0.so.0 #31 0xb7636305 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #32 0xb7639fe8 在?? () 来自 /lib/libglib-2.0.so.0 #33 0xb763a527 in g_main_loop_run () from /lib/libglib-2.0.so.0 #34 0xb7b6ae19 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

Answer 1

在这种情况下，最好再制作一个 Python 解释器并通过将 Python sn-ps 发送到那个特殊的 GTK 帮助解释器来完成所有 GTK 工作。这样你的 C 代码就不会直接使用 GTK，你只需要担心 Python 线程之间的协调。

Answer 2

这看起来像一个很长的堆栈，并且一些调用的函数看起来相同。 （例如，g_signal_emit 会通过g_closure_invoke 从自身重复调用。）

在我看来，您可能会导致堆栈溢出，可能是通过在处理信号的回调中发出信号，从而无限递归，直到您用完堆栈空间并崩溃。这只是一个猜测，我对 GTK+/GLIB 的内部结构了解不多，但这就是我闻起来的味道。我会花钱买的。 :-)

如果不是这样，那么可能是 GLIB 闭包的链接过多（一个回调调用另一个回调，该回调调用另一个回调等等，直到空间不足。）也许调整堆栈大小会有所帮助。 （我不记得是否有一种简单的方法可以为main() 执行此操作，但如果您正在创建一个新线程pthread_attr_setstacksize() 可能会有所帮助。）