On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison <[email protected]> wrote: > > > (1) Rust has great potential for *real-time programming* as well as > secure programming. Perhaps this just needs a library call to fork > "real-time threads" that never do garbage collection. ("Real-time" means > predictably meeting time deadlines, e.g. in avionics, video capture, > medical x-ray, and robotics. Speed is important but the crucial point is > reliably meeting deadlines. Garbage collectors, JIT compilers, and run-time > optimizers are bad for predictability.) Maybe Rust already has this. What > determines whether a thread-local managed heap uses reference counting? > Ref-counting may be OK in a real-time thread if it doesn't deallocate a > variable-length chain of nodes at an inconvenient time. >
Rust leaves memory allocation up to the user as much as C++. Most code can simply use unboxed values and lightweight references, with occasional usage of owned boxes (single-owner heap allocations, with lifetime tied to scope). If you need shared ownership, it's available via the `Rc`/`RcMut` types. Every split of ownership is explicit via a `clone` call since moves are the default. There will be a task-local garbage collector providing garbage collected pointers, but it still needs to be implemented. The standard library implements N:M concurrency and exposes a blocking API for asynchronous I/O. I don't think it would be suitable for a real-time application, but you can avoid the standard library: https://github.com/thestinger/rust-core Some examples: > > - Make the everyday int and uint types portable, that is, produce the > same results on all platforms. int size does matter when it varies > between 16 and 64 bits. If Rust needs an integer type that’s the size of a > pointer, call it intptr_t and only use it for that special case. > > There are fixed-size integers and floats and then the pointer-sized integers. I agree that renaming the pointer-size ones to `intptr`/`uintptr` would be great. I just filed https://github.com/mozilla/rust/issues/9940about this, so feel free to voice support there :). > > - Security holes happen whenever a program does exploitably unexpected > things. When the unexpected results happen in rarely-tested cases like > integer overflow, it’s bad for security. So consider arbitrary precision > int. > > A relatively slow big integer type exists in the standard library. There are two issues blocking it from being as first-class as the built-in types: * https://github.com/mozilla/rust/issues/4169 * https://github.com/mozilla/rust/issues/6023 > > > - AIUI, let mut x, y defines 2 mutable variables but |mut x, y| defines > mutable > x and immutable y. This is harder to learn and easier to goof. > > This syntax has been removed. The `mut` keyword will eventually be usable on variable bindings in patterns, like `let mut x = 5` or `let (x, mut y) = (1, 2). > > > - Drop C-compatible struct layout support? Is such a goal practical > considering that C struct layouts vary by CPU, compiler, and compiler > switches (enum size, pointer size, integer alignment, bit-field padding, > etc.)? C can’t reliably pass a struct to a dynamically-loaded module (that > has burned me) or to another computer (that, too). A better approach is a > library like Protocol Buffers or Cap’n Proto. > > The `struct` layout must be compatible with the platform ABI. There's no way around the need to be interoperable with existing kernels, libraries and languages, and it needs to be efficient. Rust doesn't provide any guarantees for `enum` layout, and doesn't implement bit fields. The guarantee is not intended to be used directly for serialization.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
