Essentially, yes.
On Mon, Nov 4, 2013 at 11:59 AM, Huon Wilson <[email protected]> wrote: > On 04/11/13 20:09, Oren Ben-Kiki wrote: > >> 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)... >> >> > Is this essentially an "arena allocator" where one can transfer the whole > arena and all the objects allocated in it into another task? > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
