Fallible version of Python::with_gil?

[ritikmishra]

In cases where the Python interpreter is not initialized (e.g during interpreter finalization before process exit), Python::with_gil will panic.

Is there a way where I can get the GIL in a fallible manner?

---

(I have a Rust struct that (indirectly) emits a log::info! message when dropped. I am using PyO3 to have this struct be available in Python, and to also send this log message into the Python logging module. However, if the struct is living in global Python scope, it won't be dropped until interpreter finalization)

related to vorner/pyo3-log#30

[davidhewitt]

Can you give a repro of how to cause a panic? That will help me have an idea whether a fallible form would be possible.

[ritikmishra]

Repro is here:

https://github.com/ritikmishra/with-gil-panic/blob/f222809d3255a2347e370747af674644de6d96a1/src/lib.rs#L5-L29

I tried putting the print call in the Drop implementation of a #[pyclass] directly but that did not trigger the panic.

[adamreichold]

Note that there is also another design point for a "fallible" variant of Python::with_gil, an opportunistic one which will call the given closure only if the GIL is already held, which I think might also be useful in behind-the-scenes work like Drop impls.

[davidhewitt]

We could do an opportunistic one using PyO3's own internal GIL tracking, which will be mostly right, but may be edge cases where the GIL is already held but PyO3 doesn't know it yet.

Alternatively for with_gil_fallible I wonder if checking _Py_IsFinalizing() is sufficient. Will need to check if that produces the right behaviour in the repros above.