b0edf998f8
This fixes a segfault in the reply handling code, where the destructor of a `py::function` wasn't necessarily happening with the GIL held, which could make Python segfault. The solution that was here to address this didn't work because it was relying on std::optionals, but it is possible (and apparently sometimes happens) that the std::function this lambda gets stuffed into gets moved (or maybe copied?), which then results in *two* lambda destructions: we were correctly dealing with the one that eventually gets called by clearing things properly when it gets called, but the temporary destructor also fires, and that is the one that broke. This changes it to instead leak bare pointers into the lambda and then recapture them inside when we get called; since we are guaranteed to be called exactly once, this recaptures them without losing them but doesn't incur destruction of a py::function deep in oxenmq (outside of GIL scope). |
||
|---|---|---|
| .. | ||
| oxenmq.cpp | ||