On Fri, Oct 18, 2013 at 11:02 PM, Daniel Micay <danielmi...@gmail.com>wrote:
> 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).
>
So with a suitable library, real-time threads can avoid garbage collection
pauses. Can it enforce linking to this library for all the code it calls,
or else arrange for the standard GC memory allocator to fail!() if it
accidentally called?
> 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.
>
Nice.
>
>> 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.
>
Thanks. That makes sense.
--
Jerry @1fish2
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
