Add conversions from Arc<Mutex> and Arc<RwLock> wrappers#26
Merged
Conversation
HaoZeke
reviewed
Mar 16, 2026
HaoZeke
reviewed
Mar 16, 2026
Member
HaoZeke
left a comment
There was a problem hiding this comment.
TBH I don't like ouroboros. It's a lot of codegen for what I'd think should be maybe handled with simpler lifetime transmute? like
struct ManagerContextMutex<T: 'static> {
// guard declared before _arc
// since drops are in declaration order.
guard: MutexGuard<'static, Vec<T>>,
_arc: Arc<Mutex<Vec<T>>>,
shape: i64,
stride: i64,
}and then maybe just
fn try_from(array: Arc<Mutex<Vec<T>>>) -> Result<DLPackTensor, Self::Error> {
let guard = array.lock()?; // single lock
let shape = guard.len() as i64; // extract while locked
// SAFETY: guard borrows from Mutex inside Arc (heap-allocated).
// Moving Arc doesn't invalidate the guard's internal pointer.
// Field drop order: guard drops before _arc.
let guard: MutexGuard<'static, Vec<T>> = unsafe {
std::mem::transmute(guard)
};
let mut ctx = Box::new(ManagerContextMutex {
guard, _arc: array, shape, stride: 1,
});
// ... extract pointers, build DLTensor
}
Member
Author
|
In my understanding, self referential structs are a very unsafe footgun, and I'd rather delegate support to an external crate for this. |
Open
4 tasks
Member
|
Feel free to merge after the typo fix |
This allows sharing data that can be modified both by Rust and the DlPack consumer, using locks to enforce borrowing rules at runtime
The deleter functions were instantiated with the element type T (e.g. f64) instead of the full Array<T, D> type. This caused Box::from_raw in the deleter to reconstruct a Box with incorrect layout (size 32 instead of 88 for Array<f64, Ix2>), leading to undefined behavior on deallocation. The existing tests masked this bug by keeping an Arc::clone, so the refcount never reached zero and the deleter never actually deallocated. Add last-ref tests that pass ownership of the sole Arc into the tensor, exercising the real deallocation path. Confirmed via miri.
There were a couple of violations of stacked borrow that where fixed by using `Box<i64>` instead of inline i64 for the shape/stride values. Co-Authored-By: Guillaume Fraux <guillaume.fraux@epfl.ch>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This allows sharing data that can be modified both by Rust and the DlPack consumer, using locks to enforce borrowing rules at runtime.
We store both the
Arc<Lock>and theLockGuard<'a>in the DLPack context to ensure that we both keep the data alive in the Arc, and hold the corresponding lock. The resulting self-referential struct (i.e. struct that borrows itself) is created through ouroboros.