On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison <jhm...@gmail.com> 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).
>
Ideally, forking a real-time thread could ensure that (1) no GC pauses the
thread just to find out there's no garbage to collect, and (2) something
would catch the mistake if it ever calls code (directly or indirectly) that
evolves to using GC memory.
> 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.
>
Sounds good, although I don't understand the details. Does the program pick
between GC allocation and ref counting allocation via the choice of pointer
sigils? Via the choice of library calls?
> 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
>
What's N:M concurrency?
>
> 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 :).
>
Will do.
>
>
>>
>> - 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.
>
Ah. It focuses on the core cases.
A case that crashed on me was calling libjpeg.so when compiled with a gcc
switch that set small enums. A student put that switch in the make file
because he got burned by enum sizes when calling the OS on a Chumby.
--
Jerry
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
