更新好吧,看起来在调用PyGILState_Ensure()之前添加PyEval_InitThreads()就可以了.在我急于解决问题时,我错误地将我的"挂起"归因于PyEval_InitThreads().
但是,在阅读了一些Python文档后,我想知道这是否是正确的解决方案.
当未知哪个线程(如果有)当前具有全局解释器锁时,调用此函数是不安全的.
首先,我正在研究一些经过修改的GNU Radio代码 - 特别是修改过的gr_bin_statistics_f块.现在,有一个错误报告(虽然是一个旧报告)几乎描述了我的确切情况.
http://gnuradio.org/redmine/issues/show/199
现在,bug报告中提到的usrp_spectrum_sense.py调用gr_bin_statistics_f(C++),然后定期回调Python以重新调整USRP(无线电).
以下是调用Python代码时发生的情况:
PyGILState_STATE d_gstate;
d_gstate = PyGILState_Ensure();
// call python code
PyGILState_Release(d_gstate);
因此,一旦我们从Python代码返回,当调用PyGILState_Release(d_gstate)时就会发生分段错误.虽然我的代码和原始的gr_bin_statistics_f之间存在差异,但似乎没有任何东西与此远程相关.
我读到在PyGILState_Ensure()之前调用PyEval_InitThreads()已经解决了一些人的问题,但它只是导致我的程序挂起.
任何人都可以为我阐明这一点吗？或者只是时候发送消息到GNU Radio邮件列表？
在Fedora 14 x86_64上使用Python2.7.
这是GDB的回溯:
(gdb) c
Continuing.
[New Thread 0x7fabd3a8d700 (LWP 23969)]
[New Thread 0x7fabd328c700 (LWP 23970)]
[New Thread 0x7fabd2a8b700 (LWP 23971)]
[New Thread 0x7fabd228a700 (LWP 23972)]
[New Thread 0x7fabd1a89700 (LWP 23973)]
[New Thread 0x7fabd1288700 (LWP 23974)]
[New Thread 0x7fabd0a87700 (LWP 23975)]
[New Thread 0x7fabbbfff700 (LWP 23976)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to …