Bump version to 0.11.0 #989
Conversation
|
Shall we add a migration guide? I think we can mention stable Rust as well as |
Sounds good 👍 |
|
Cool I'll try to write this early evening today. Tomorrow morning at the latest. |
| Because `#[pyclass]` structs can be sent between threads by the Python interpreter, they must implement | ||
| `Send` to guarantee thread safety. This bound was added in PyO3 `0.11.0`. | ||
|
|
||
| This may "break" some code which previously was accepted, even though it was unsound. To resolve this, |
There was a problem hiding this comment.
We should note that 'if you are sure that your class is not sent to another thread, you can use unsafe impl Send for YourClass {}' first. Actually it's rare to send pyclass to another thread, and I saw some #[pyclass]es that have a raw pointer internally and need unsafe impl Send when investigating the effect of this change.
This may "break" some code which previously was accepted, even though it was unsound.
Also, we have to note that it's theoretically unsound, but not problematic when the class is not actually sent to another thread by:
- Python's threading module
py.allow_threadsandPy
There was a problem hiding this comment.
We should note that 'if you are sure that your class is not sent to another thread, you can use
unsafe impl Send for YourClass {}' first.
I don't think that's good advice. It undermines protections on the Rust side, too.
Also, we have to note that it's theoretically unsound, but not problematic when the class is not actually sent to another thread by:
I don't know about your experience, but I use the threading module quite a lot in Python, and objects are accessed freely from any thread there.
There was a problem hiding this comment.
Thank you for the feedback.
I don't know about your experience, but I use the threading module quite a lot in Python, and objects are accessed freely from any thread there.
Maybe it's because I use Python mainly for machine learning research, where CPU/GPU bound is dominant.
Then I would rather take back my words... but I still think we should note that unsafe impl Sync can be the easiest fix. Maybe it's also helpful to link std::marker::Send or nomicon.
There was a problem hiding this comment.
I'm not keen on suggesting unsafe impl Send or unsafe impl Sync - to me that feels like the kind of hack where "I know that I'm not using threads now, so I can skip writing safe code". Later on this hack is forgotten, the code gets edited to include threading and suddenly very strange bugs / crashes / undefined behaviour.
EDIT: changed my mind. I'm ok to suggest adding unsafe impl Send as long as we carefully explain that the responsibility is on the user to ensure the type is also thread-safe. But we have to explain this really clearly - because the undefined behaviour the user might see if they get this wrong could be pretty bad.
(My description of using unsafe impl Send as a hack still applies when the user uses it to skip making a type thread-safe.)
Adding in a link to docs / nomicon would be fine though.
|
I added a sentence about |
kngwyu
force-pushed
the
release-0.11
branch
3 times, most recently
from
b35e193 to
76e677e
Compare
guide/src/migration.md
Outdated
| Or if you feel it hard to make your `#[pyclass]` struct automatically sendable | ||
| (e.g., in case it has a raw pointer), you can use `unsafe impl Send`. |
There was a problem hiding this comment.
| Or if you feel it hard to make your `#[pyclass]` struct automatically sendable | |
| (e.g., in case it has a raw pointer), you can use `unsafe impl Send`. | |
| Or in situations where you cannot change your `#[pyclass]` to automatically implement `Send` | |
| (e.g., when it contains a raw pointer), you can use `unsafe impl Send`. |
|
Thanks! |
The first version that can be used with stable Rust.
rust-numpy