从C/C ++程序调用的多个操作系统线程上的多个独立的嵌入式Python解释器 [英] Multiple independent embedded Python Interpreters on multiple operating system threads invoked from C/C++ program
问题描述
在 C/C ++应用程序中嵌入Python解释器已有详细记录.从C/C ++应用程序调用的多个操作系统线程(即同一进程中一个操作系统线程的一个解释器)上运行多个python解释器的最佳方法是什么?此类应用程序还可能存在与内存碎片和Py_Finalize()的限制有关的问题.
Embedding Python interpreter in a C/C++ application is well documented. What is the best approach to run multiple python interpreter on multiple operating system threads (i.e. one interpreter on one operating system thread within the same process) which are invoked from the C/C++ application? Such applications may also have problems related to memory fragmentation and limitations of Py_Finalize().
一种这样的方法可以是:
One such approach can be the following:
- Python线程，因此在pyconfig.h中禁用了GIL，以使其保持简单(#undef WITH_THREAD)
- Python解释器源代码的所有可变全局变量均已移动到通过线程本地存储引用的堆分配结构(参考:我的问题是:
- 有没有更好的方法?
- 是否有任何工具可以自动将Python Interpreter源代码的全局变量转换为通过TLS(线程本地存储)引用的堆分配结构?
这里讨论了类似的主题:
Similar topics are discussed here:
- Multiple independent Python interpreters in a C/C++ program?
- Multiple python interpreters within the same process
- Lua Versus Python
推荐答案
这并不完全是您的问题的答案，但是您可以使用单独的进程而不是线程，那么问题应该消失.
It's not exactly an answer to your question, but you could use separate processes instead of threads, then the problems should vanish.
优点:
- 无需破解python(并确保结果在所有预期的情况下均有效)
- 总体上开发工作可能更少
- 轻松升级到新的python版本
- 不同进程之间的接口定义清晰，因此更容易正确调试
缺点:
- 根据您的平台，可能稍微有些超重(相对轻量级的Linux进程)
如果您将共享内存用于IPC，则您得到的应用程序代码与线程得到的代码应该不会有太大差别.
If you use shared memory for IPC, your resulting application code shouldn't differ too much from what you'd get with threads.
鉴于有些人认为您应该始终在线程上使用进程，如果可以通过任何方式满足您的约束，我至少会认为它是替代方法.
Given that some people are arguing you should always use processes over threads, I'd at least consider it as an alternative if it fits your constraints in any way.
这篇关于从C/C ++程序调用的多个操作系统线程上的多个独立的嵌入式Python解释器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
