On Monday, 30 September 2013, Oren Ben-Kiki wrote: > Yes, it is very much like an arena... And yes, the idea is that all the > pointers are contained in it, so the ~arena as a whole should be safe to > send, but that contradicts using @ - maybe it could be re-written using > Rc... hmmm. At any rate, thanks for the pointer - I wasn't aware of arenas > before. > > Another hmmm... An arena sounds a lot like a weak version of a GC-ed > heap... So here's a thought: What if @ pointers had a heap associated with > them, just like & pointers have a lifetime? We have the task-global @ heap, > and we have the static & lifetime... but we can explicitly manage & > lifetimes - how about if we could explicitly create a new Gc-heap use it to > happily muck about with @'my-heap pointers (which would be statically > prevented from being mixed with @'other-heap pointers), and be able to send > the whole heap between tasks, etc.? (Not that I necessarily suggest @'heap > as a syntax, but you get the idea) > > Gc would still run in the context of one heap at a time... but this would > remove the restriction of one task <=> one heap. >
This would be neat, yes. In this case, accessing such a heap would be conceptually identical to temporarily joining a task, except without the overhead of having to schedule it, since it would have no independently executing code. Figuring out how to hook it into the GC would be a neat trick... As for what a macro would expand to, I was thinking more that it would expand to the containing structure and some smart references that use lifetimes to ensure that the containing structure is pinned during their existence and that they don't outlive it. You'd have to interact with it using methods which make sure you can't break any of the invariants, such as aliasing something and then trying to freeze it. To what extent you could do this statically rather than dynamically, I'm not sure, but lifetimes are a fairly powerful concept, so it's plausible one could work something out. Doing it dynamically would basically mean using Cells modified to have lifetimes as the smart references into the structure. It would be nice to have a version of the smart references that ensured you didn't externally alias something which is also externally mutable, though.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
