ARCs have their place, sure! But "letting it leak" isn't acceptable in my case.
Instead, in my use case, "no deletes until the whole heap is released" makes way more sense (heaps are small, grow a bit, and get released). Since the lifetime of the object becomes == the lifetime of the heap, there's no issue with cycles. There's only an issue with multiple mutations, which like I said only needs a bit per pointer (and a non-atomic one at that as each heap is accessed by one thread - the only thing that gets sent between tasks is the whole heap!). So... different use cases, different solutions. ARC is a different trade-off. I guess the right thing to do would be to implement some "sufficiently smart" AppendOnlyHeap<T> pointer, but this seems hard to do (same heap can hold objects of multiple types, etc.) so for now I have some AlmostSafeHeapPointer<T> instead :-( Language support for heaps-separate-from-tasks would have solved it (and a bit more)... On Mon, Nov 4, 2013 at 8:32 AM, Daniel Micay <danielmi...@gmail.com> wrote: > On Mon, Nov 4, 2013 at 1:29 AM, Oren Ben-Kiki <o...@ben-kiki.org> wrote: > >> Even if RC allowed cycles (I don't quite see how...) the whole thing >> wouldn't be send-able, unless one uses ARC. But ARC has even more >> performance penalties than RC... And doing cycle-supporting ARC across >> tasks seems like pushing it - you might as well admit you are doing global >> GC in the 1st place. >> > > It can't support ownership cycles but it can certainly support cyclic > links like `std::shared_ptr` + `std::weak_ptr` in C++. The performance > penalty for supporting sends between tasks is atomic reference counting and > the price for supporting weak pointers is an extra word per box. >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
