New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when using local_future_into_py
or local_future_into_py_with_locals
#71
Comments
You are not using that function inside a LocalSet, which is what caused that panic. https://docs.rs/pyo3-asyncio/latest/pyo3_asyncio/tokio/fn.local_future_into_py.html#examples Although that example only demonstrates how you await a local future in a main function in rust, not from python. So I am not very sure on how you should do that either. I think this is related to #59 |
Thanks @Cryptex-github, you're correct that the lack of a LocalSet is what's causing this to panic in Tokio. I've always found Tokio's There is some question around whether these conversions are useful or not. I was considering deprecating them, so I'd be interested to hear more about your use-case to see if they still provide some value. The main reason they're a bit problematic is because they can't really be called from Python unless the Python is running on a Rust executor. The Python executor and Rust executors live on separate threads, so |
alright thanks for the response, so basically at the moment there is no good solution or workaround for such? other than not having I currently switched to a sync implementation but I would still like to make an async one if possible in the future |
There's usually a way to make |
woop, sorry I think I made a mistake on my end, my bad. tokio's RwLock's read/write guards are not |
Your problem looks very similar to #50 since you're trying to use a borrowed Sounds like putting the data in an I can't see the full type of your |
ah yea so I ended up going with I think the read and write locks there do implement
here's the code I have currently it works with a simple test but just making sure I haven't done anything wrong or missed anything that could result in a hidden problem. Thanks! |
Async mutexes work too, so I think you're good! And they don't have the restriction that I mentioned. Some (all?) synchronous mutexes do though, including In your case it looks like the async mutex is appropriate since the operations that you want to call on Akinator are async themselves. Sometimes you need to use a mutex in both sync and async contexts, so it's nice to be able to use a sync mutex in those cases. What I mentioned was this situation let mut guard = mutex.lock().unwrap();
operation.await; // lock guard can't be held across this await (error might mention MutexGuard being !Send)
guard.value = 1; Instead you can ensure that the guard is dropped before the next await {
let mut guard = mutex.lock().unwrap();
guard.value = 1;
}
operation.await; |
when using
local_future_into_py
/local_future_into_py_with_locals
and then when I try to call the python functions this gets raisedI was using
local_future_into_py
at first and got such error and a friend recommended me to trylocal_future_into_py_with_locals
instead but I did such with no change in output.code here: https://github.com/Tom-the-Bomb/akinator.py
thanks in advance
The text was updated successfully, but these errors were encountered: