On Sat, Oct 19, 2013 at 12:45 AM, Jerry Morrison <jhm...@gmail.com> wrote:
>
> 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.
>
Rust doesn't currently have a way to forbid features only in some parts of
the code but not others. Avoiding garbage collection as a hard requirement
will likely mean using rust-core (or whatever it evolves to, maybe a
special profile of the standard library).
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?
>
Reference counting is implemented as a library type, so you would make a
reference counted allocation with `Rc::new(value)` and make an explicit
reference count with `box.clone()` (the implementation:
https://github.com/mozilla/rust/blob/master/src/libstd/rc.rs).
There are managed pointers sigils for garbage collection (@, @mut) but I
think consensus is trending towards replacing the syntax with a type
similar to `Rc` allowing cycles and implicit copies. The compiler support
could be exposed via attributes hooks like the operator traits, rather than
syntax.
> 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?
>
The concurrency model implemented in the standard library treats real
threads as schedulers, and maps cooperatively scheduled tasks onto them. If
the task doesn't make calls to functions with yields, it will monopolize a
scheduler thread.
It's a very good model for I/O or for high throughput on many CPU-bound
batch jobs (https://www.threadingbuildingblocks.org/), but it's not going
to be suitable for real-time needs.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
