How to make my thread not block further code execution: binding python rust #3665
-
Hi folks, I'm a beginner on PyO3, and I'm interested in creating a binding between my Python code and my Rust code. I want to implement a class in Rust that will be manipulated in my Python code. In my Python code, I create an instance of the class in Rust, then in a thread I call a method of the class created in Rust, then I continue my processing. But it turns out that when I start my thread, my Python code waits for the end of the execution of my Rust function called in the thread before executing the rest of the operations. I'd like this to be in background and not block my code, especially as I need to manipulate the same object created earlier in my code. Does anyone have any ideas on how to solve this problem? Here's a link to a little example I made: https://github.com/cyrus937/pyo3_example.git Thanks in advance |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
There are multiple ways to approach what you are trying to do. Either using async I/O to achieve concurrency on the Python side. Or by starting a new thread on the Rust side to sleep and print after the delay. Note that this implies that you need to share your pyclass with that thread, e.g. by taking // Print the informations after 10 seconds
fn display(slf: Py<Self>, py: Python<'_>) {
let cloned = slf.clone_ref(py);
std::thread::spawn(move || {
println!("Wait 10 seconds before print informations....");
let sleep_time = time::Duration::from_millis(10000);
thread::sleep(sleep_time);
Python::with_gil(|py| {
let slf = cloned.borrow(py);
println!(
"My name is {} and my description is : {}",
slf.name, slf.description
);
});
});
slf.borrow_mut(py).is_display = true;
} |
Beta Was this translation helpful? Give feedback.
There are multiple ways to approach what you are trying to do. Either using async I/O to achieve concurrency on the Python side. Or by starting a new thread on the Rust side to sleep and print after the delay.
Note that this implies that you need to share your pyclass with that thread, e.g. by taking
slf: Py<Self>
as the self parameter and passing that to the background which will then have to usePython::with_gil
to acquire the GIL before accessing the properties of you pyclass, e.g.