-
-
Notifications
You must be signed in to change notification settings - Fork 63
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
Add CudaSlice::split_at_mut
and CudaViewMut::split_at_mut
#235
Conversation
Yeah we could probably add some doctests that should fail to each of these methods. The main thing we have to make sure still works properly is the ownership/borrow semantics. We need to check if moving the references from the root variable to PhantomData changes these. Ideally would want |
CudaView
and CudaViewMut
to allow for splitting of mutable views.CudaView
and CudaViewMut
to allow for splitting of mutable views.
07e50ac
to
4a96aac
Compare
I have added some doc-tests to show the borrowing behavior of CudaView and CudaViewMut, and also rebased on main |
As a sidenote the no-std feature is incompatible with the tests, since they use Vec. |
It's fine to include here, will merge after piplines pass. Thanks for adding this feature! |
CudaView
and CudaViewMut
to allow for splitting of mutable views.CudaSlice::split_at_mut
and CudaViewMut::split_at_mut
This is an attempt to address #233.
Since this is code that touches some aspects of the lifetimes of
CudaView
andCudaViewMut
, this could use some extra scrutiny to check if the safety invariants of the involved types are still ok.I removed the
root
field of bothCudaView
andCudaViewMut
, since it's only purpose was AFAIK, to keep track of the lifetimes of the respective structs. I have moved this into aPhantomData
which should serve the same purpose.Furthermore, I have now added the
split_at_mut
methods toCudaSlice
andCudaViewMut
, which mimic the behavior ofsplit_at_mut
of the standard library.The old method of storing a
&mut
to the cuda device pointer does not work for splitting, since it would mean that there exist two mutable references to the same value (the u64 device ptr value) at the same time, which AFAIK is always unsound. Therefore the removal and moving the lifetimes into PhantomData as discussed above.