Open ClawSeven opened 1 year ago
The PointerOps
trait provides all the flexibility needed to support custom allocators: you need to hold a copy of the allocator in your custom MyPointerOps
object and use it to reconstruct a Box<T, A>
from a *const T
.
However since you are using a custom PointerOps
, you cannot use the intrusive_adapter
macro and need to make a type that implements the Adapter
trait manually.
No changes to this crate are needed, it's just that you can't use the DefaultPointerOps
and intrusive_adapter!
helpers with custom allocators.
Wow, thank you for the elegant solution! By the way, does the intrusive-rs crate support raw pointers? I understand that I may need to implement a custom PointerOps, but I am wondering if there is any additional work required to support raw pointers.
I have found that there is an UnsafeRef pointer available in the intrusive-rs crate. I can use this pointer instead of raw pointers, and free the memory by myself. Your design is very well thought out.
Hi, Amanieu,
I encountered some issues while developing memory management (MM) using an intrusive linked list. As you may know, the Box pointer uses #global_allocator to allocate and deallocate memory on the heap. However, in the kernel, the memory allocated by #global_allocator needs to be managed. Therefore, I have implemented a customized allocator for Box, called Alloc.
However, the current intrusive implementation does not allow for the specification of allocators, and PointerOps trait is only implemented for Box<T, Global>. In issue #87, I applied generic associated types and provided an implementation, but it is not ideal. I am struggling to come up with a better solution.
The current implementation allows us to specify allocators when using the intrusive_adapter macro, as shown here:
I would appreciate your assistance in finding a better solution that supports specifying allocators. I look forward to your reply.