> Restructuring your code to avoid cycles is problematic when you're
> implementing a platform where the spec allows users to create ownership
> cycles --- like, say, the Web platform. So if
> Rust didn't support cyclic ownership, Servo would have to implement its own
> GC and tracing code just like Gecko does. That's a situation we need to get
> away from.
Yes, my idea was to essentially extend the compiler with facilities allowing to
implement RcMut<T> and RWARC<T> in such a way that they can be nested without
creating memory leaks (subject to some restrictions, but less restrictions than
the blanket inability to nest), with the goal of replacing C++ (or Java,
perhaps) in high-performance multithreaded servers and kernels.
That would be orthogonal to the issue of what to do with @-pointers and whether
to have garbage collection (which is indeed very desirable since some programs
need it).
> An interesting meta-point is that when you're implementing a platform, rather
> than a specific application, you have much less freedom to structure the
> implementation because you don't
> know what any given instance of your system actually does. This affects
> everything from the requirements on the programming language to the design of
> graphics APIs.
Yes, although note that while task-local GC is sufficient to implement a
browser with JavaScript (since JavaScript is single threaded), it would not be
enough to implement an high-performance Java VM, which requires GC on memory
simultaneously accessible by multiple threads.
In general, it would be nice to have great support for all 4 models:
sophisticated local and global reference counting, and local and global GC (as
well as owned and borrowed pointers).
It's probably reasonable though for Mozilla to mostly focus on the browser use
case.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
