mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: Tweak the wording of the memory model goals

Browse Source
This commit is contained in:
Patrick Walton 2012-10-09 21:39:18 -07:00
parent 6da09c3b43
commit d9317a174e
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/tutorial.md
View File

@ -988,16 +988,17 @@ illuminate several of Rust's unique features as we encounter them.
Rust has three competing goals that inform its view of memory:
* Memory safety: memory that is managed by and is accessible to the
Rust language must be guaranteed to be valid; under normal
* Memory safety: Memory that is managed by and is accessible to the
Rust language must be guaranteed to be valid. Under normal
circumstances it must be impossible for Rust to trigger a
segmentation fault or leak memory
* Performance: high-performance low-level code must be able to employ
a number of allocation strategies; low-performance high-level code
must be able to employ a single, garbage-collection-based, heap
allocation strategy
* Concurrency: Rust must maintain memory safety guarantees, even for
code running in parallel
segmentation fault or leak memory.
* Performance: High-performance low-level code must be able to employ
a number of allocation strategies. Tracing garbage collection must be
optional and, if it is not desired, memory safety must not be compromised.
Less performance-critical, high-level code should be able to employ a single,
garbage-collection-based, heap allocation strategy.
* Concurrency: Rust code must be free of in-memory data races. (Note that other
types of races are still possible.)
## How performance considerations influence the memory model