Open simnalamburt opened 1 month ago
I believe you're right; it should be possible to relax the type restriction by allowing ?Sized
. Additionally, I think using ThinBox
for pointer tagging may not be necessary since we can still determine the available width of the low bits statically (see low_bits<T>()
), similar to what crossbeam-epoch
does.
This library started as a proof-of-concept implementation of the original paper, and at that time, we did not consider unsized types. I believe it's now time to support them for broader applicability, as well as for cross-type tracing (#4).
That sounds great. Making it more user-friendly like this will not only increase the value of the research results but also raise more awareness about Safe Memory Reclamation. SMR research has made tremendous progress, but we need to address the current situation where developers are still resorting to using std::sync::Arc
.
Currently,
circ
users can still use it with!Sized
types, albeit a bit inconveniently, by coding likeAtomicRc<Box<T>>
. If the fat pointer is bothersome,AtomicRc<ThinBox<T>>
could be used instead. It would be more convenient ifcirc
handled this automatically. Is there a specific reasoncirc
only supportsSized
types?(This is probably a question I could answer by reading the code, but I haven’t had a chance to look into it deeply. Sorry, haha ;) )