在C/C++程序中调用多个独立的嵌入式Python解释器，运行在多个操作系统线程上。
在C/C++程序中调用多个独立的嵌入式Python解释器，运行在多个操作系统线程上。
在一个C/C++应用程序中嵌入Python解释器的方法已经有很好的文档记录。在多个操作系统线程上运行多个Python解释器的最佳方法是什么（即在同一进程中的一个操作系统线程上的一个解释器），这些解释器是由C/C++应用程序调用的？这种应用程序可能还会遇到与内存碎片化和Py_Finalize()的限制相关的问题。\n其中一种方法可以是以下方式：\n
- \n
- 在pyconfig.h中禁用Python线程和GIL，以保持简单（#undef WITH_THREAD）
- 将Python解释器源代码的所有可变全局变量移动到通过Thread Local Storage引用的堆分配的结构中（参考：Python on a Phone）。
\n
\n
\n我的问题是：\n
- \n
- 有更好的方法吗？
- 有没有工具可以自动将Python解释器源代码的全局变量转换为通过TLS（Thread Local Storage）引用的堆分配的结构？
\n
\n
\n类似的主题在这里讨论：\n
- \n
- 在C/C++程序中使用多个独立的Python解释器？
- 在同一进程中使用多个Python解释器
- Lua与Python的比较
\n
\n
\n
多个独立嵌入式Python解释器在多个操作系统线程上被从C/C++程序调用的原因是为了解决与线程相关的问题。然而，使用单独的进程代替线程可以消除这些问题。
解决方法是使用单独的进程代替线程。这样做有以下优点：
- 无需修改Python并确保结果在所有预期情况下都有效
- 总体开发工作量可能较小
- 方便升级到新的Python版本
- 不同进程之间有明确定义的接口，因此更容易正确使用和调试
然而，使用进程代替线程可能有以下缺点：
- 根据平台的不同，可能会稍微增加资源开销（在Linux上使用相对轻量级的进程）
如果使用共享内存进行进程间通信，最终的应用程序代码与使用线程时应该没有太大区别。
考虑到一些人认为应该始终使用进程而不是线程，如果满足任何约束条件，我至少会考虑使用进程作为一种替代方案。