On Sun, Oct 28, 2012 at 8:48 PM, Niko Matsakis <[email protected]> wrote:
> Regardless of whether manual memory management is desirable as an end > goal, support for it is essentially required if you wish to permit tasks to > exchange ownership of data without copies. For example, in Servo we have a > double-buffered system where mutable memory buffers are exchanged between > the various parts of the system. In order to make this safe, we have to > guarantee that this buffer is unaliased at the point where it is sent—if > you know it's unaliased, of course, you also know that you could safely > free it. > > As a broader point, it turns out there are a LOT of type system things you > can do if you know something about aliasing (or the lack thereof). Our > current approach to freezing data structures for example is reliant on > this. Safe array splitting for data parallelism—if we ever go in that > direction—will be reliant on this. And so forth. So, supporting a > unique-pointer-like construct makes a lot of sense. > > > Niko > > I really think this is the core point: unique/borrowed/shared are less about memory management than about ownership semantics. It would be perfectly viable (albeit slower) to treat them all identically in terms of codegen (ie, GC'em all). On the other hand, ownership semantics provide both the developer and the compiler with *guarantees* upon which they can build. -- Matthieu > John Mija <[email protected]> > October 28, 2012 4:55 AM > Does make sense to have a language with manual memory management since > it's possible to create stuff of low level with a specialized garbage > collector? > It's good to create drivers, but it's already C. > > > i.e. Both Native Oberon and Blue Bottle operating systems were implemented > in languages, Oberon and Active Oberon, which have type safety and > concurrent (at least in compiler ulm oberon) GC support. > > http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf > > > Then, Java is being used in embedded and real-time systems with a > deterministic garbage collection: > > http://www.pr.com/press-release/226895 > _______________________________________________ > 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 > >
<<compose-unknown-contact.jpg>>
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
