Closed lachlansneff closed 3 years ago
Sadly this isn't possible, I already tried that in the alloc-wg
crate. When taking self
, a Copy
bound is needed on AllocRef
, otherwise most collection wouldn't work without many alloc.clone()
. Requiring Copy
or Clone
is not possible as &mut
does not implement it.
@TimDiekmann Yeah, I see. That is unfortunate. My other idea is that there could be two allocator traits, AllocRef
and SyncAllocRef
.
It'd look something like this:
pub unsafe trait SyncAllocRef: Sync + Send {
fn alloc(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocErr>;
unsafe fn dealloc(&self, ptr: NonNull<u8>, layout: Layout);
// ...
}
unsafe impl<A> AllocRef for A where A: SyncAllocRef {
fn alloc(&mut self, layout: Layout) -> Result<NonNull<[u8]>, AllocErr> {
<Self as SyncAllocRef>::alloc(self, layout)
}
unsafe fn dealloc(&mut self, ptr: NonNull<u8>, layout: Layout) {
<Self as SyncAllocRef>::dealloc(self, ptr, layout)
}
}
Then, regular collections could just take an AllocRef
and any allocator would work for them, and concurrent collections could explicitly take a SyncAllocRef
.
It's explicit, idiomatic in all circumstances, and doesn't result in performance pitfalls.
The idea isn't new, but I totally forgot about this approach, thank you for bringing this back! However I think this should be discussed in #55. I close this in favor of the other issue.
I feel like this would provide the most ergonomic solution for working with both single-threaded and multi-threaded collections.For a stack allocator, you'd pass&mut A
into the collection. For a collection like a shared hashmap, you'd use an allocator that supported concurrent allocations and pass in&A
.AllocRef
would be implemented for either&A
and&mut A
depending on if it was concurrent or not.It's definitely possible I'm not seeing some downsides of this, but it seems like the best of both worlds to me.See my reply lower down.