使用pybind11从C++调用Python函数的正确方式及死锁疑问

你的pybind11版本实现其实已经可以正常运行，不过针对你提出的两个核心疑问（py::object vs py::function、死锁风险），咱们可以做更严谨的优化和说明：

1. 应该用py::function而非py::object吗？ #

答案是推荐使用py::function，原因有两个：

• 语义更明确：py::function是py::object的子类，专门用来表示Python中的可调用对象（函数、lambda、实现了__call__的类实例等），用它存储回调变量，代码的可读性和意图表达会更清晰。
• 自动类型检查：当你把参数声明为py::function时，pybind11会自动验证传入的对象是否可调用，如果传入的是不可调用的对象（比如普通字符串、整数），会直接抛出Python异常，提前避免后续调用时的错误。

修改后的严谨版本代码：

namespace py = pybind11;
py::function _cbEvent; // 替换为py::function类型

void setCallBackOnEvent(py::function func) { // 参数也用py::function约束
    _cbEvent = func;
}

void OnEvent(std::string message) {
    py::gil_scoped_acquire acquire; // RAII式GIL管理，更安全
    _cbEvent(message); // py::function重载了operator()，直接调用更简洁
    // 作用域结束时自动释放GIL，无需手动调用PyGILState_Release
}

2. 死锁风险的规避 #

你的顾虑是合理的，但只要正确管理GIL，一般不会出现死锁，核心注意点如下：

• GIL管理的更优方式：
  你原来用PyGILState_Ensure()和PyGILState_Release()是正确的，但更推荐pybind11提供的RAII类py::gil_scoped_acquire和py::gil_scoped_release——它会在作用域结束时自动释放资源，避免因忘记调用PyGILState_Release()导致的GIL泄漏，进而引发死锁或其他线程问题。
• 线程场景区分：
  • 如果OnEvent是由Python线程触发的（比如Python调用C函数后，C同步调用OnEvent），此时线程已经持有GIL，py::gil_scoped_acquire会直接复用当前GIL，不会有问题。
  • 如果OnEvent是由C++后台线程触发的，必须先获取GIL才能调用Python对象，py::gil_scoped_acquire会自动处理GIL的获取，这也是你当前代码能正常运行的核心原因。
• 避免循环回调：
  死锁的潜在风险更多来自循环回调（比如Python回调中再次调用C++模块的函数，该函数又触发OnEvent回调），这种情况会导致无限递归调用，最终引发栈溢出而非死锁。只要你的业务逻辑中避免这种循环触发，就不会有问题。

额外的安全性优化 #

对比你原来的boost::python实现，pybind11的py::function/py::object会自动管理Python对象的引用计数，无需手动调用Py_INCREF或Py_DECREF——而你原来的boost代码其实遗漏了对_pyCallBackEvent的引用计数增加，存在Python侧销毁回调函数后导致C++侧指针失效的风险，pybind11的实现则天然规避了这个问题。

内容的提问来源于stack exchange，提问作者Sharath