re sub graphs , when you use a borrowed pointer and pass to another task it transfer all the data by value , this is what its probably referring to. They also have some object cloning mechanism ..
How does deep copy on return break region unfication ? Unless there are external references in the data Isn't it just new data ... and hence we can treat it as a void return ? In rust such references can only be a shared / gc pointer ( as you say non borrowed) as it would be illegal to pass a reference to private data for the task to another task. On Tue, Jul 30, 2013 at 12:40 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Mon, Jul 29, 2013 at 6:54 AM, Bennie Kloosteman <[email protected]>wrote: > > >> Rust doesnt just hand object graphs , by default most passing is by >> value with the GC pointers being less used . >> > > Sure. But the problems only become interesting when returning heap-based > objects, so I was focusing on that. > > Some of the Rust docs talk about owned objects and transferring entire > subgraphs, so it seems like Rust *does* have a notion of subgraph return. > I can't tell from the various documentation sources how that works. > > >> Yes passing by deep copy is a good thing and far too little used the >> amount of CPU lost in multithreaded contention is shocking. >> > > Either deep copy or deep frozen, yes. But just to make sure I was clear, I > was noting that deepcopy-on-return can also be used to break region > unifications that might prevent eager reclaim. > > Though in a discussion last night with Matt Rice I realized that any case > that unifies the regions will necessarily have an assignment to a > non-borrowed pointer. > > >> Personally i think we are no where near to a solution yet of running >> cross task comms on a shared GC .. Singularity had a good go at it . >> > > And it's likely that we don't want to, unless we can come up with a single > GC that works for all scenarios. This is required because object headers > change depending on the GC, which makes cross-process pointers problematic. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
