once_cell::sync both use locks to ensure that initialization is performed only by a single thread. Because the Python GIL is an additional lock this can lead to deadlocks in the following way:
- A thread (thread A) which has acquired the Python GIL starts initialization of a
- The initialization code calls some Python API which temporarily releases the GIL e.g.
- Another thread (thread B) acquires the Python GIL and attempts to access the same
- Thread B is blocked, because it waits for
lazy_static's initialization to lock to release.
- Thread A is blocked, because it waits to re-aquire the GIL which thread B still holds.
PyO3 provides a struct
GILOnceCell which works equivalently to
OnceCell but relies solely on the Python GIL for thread safety. This means it can be used in place of
once_cell where you are experiencing the deadlock described above. See the documentation for
GILOnceCell for an example how to use it.
I can't run
cargo test: I'm having linker issues like "Symbol not found" or "Undefined reference to _PyExc_SystemError"!
Currently, #341 causes
cargo test to fail with linking errors when the
extension-module feature is activated. For now you can work around this by making the
extension-module feature optional and running the tests with
cargo test --no-default-features:
[dependencies.pyo3] version = "*" [features] extension-module = ["pyo3/extension-module"] default = ["extension-module"]
The Rust book suggests to put integration tests inside a
For a PyO3
extension-module project where the
crate-type is set to
"cdylib" in your
the compiler won't be able to find your crate and will display errors such as
error[E0432]: unresolved import `my_crate` --> tests/test_my_crate.rs:1:5 | 1 | use my_crate; | ^^^^^^^^^^^^ no external crate `my_crate`
The best solution is to make your crate types include both
# Cargo.toml [lib] crate-type = ["cdylib", "rlib"]
This is because Ctrl-C raises a SIGINT signal, which is handled by the calling Python process by simply setting a flag to action upon later. This flag isn't checked while Rust code called from Python is executing, only once control returns to the Python interpreter.
You can give the Python interpreter a chance to process the signal properly by calling
Python::check_signals. It's good practice to call this function regularly if you have a long-running Rust function so that your users can cancel it.