Vladimir Pouzanov <[email protected]> writes: > There is a number of options on the memory side of things. I feel that > stack usage could be estimated a bit more simply with rust and it's > __morestack support, so that it would be possible to run a few threads with > preemptive scheduling (__morestack also guarantees that no memory > corruption would occur due to stack overflow). > Unfortunately this replaces the ugly possibility of unpredictable crashes with the slightly less ugly possiblity of unpredictable deadlocks if we run out of stack in the middle of execution. Perhaps threads could be annotated with their maximum expected stack size, allowing stack chunks to be allocated at spawn-time.
> I'm totally against "unmanaged" heap support and ~T on embedded, that just
> doesn't work. It's a very big burden to support that reasonably in existing
> C/C++ RTOSes out there, so I don't want to spend lots of time trying to
> solve the same problems. Still, heap is really useful in some cases (as
> I've figured out while working on 802.15.4 stack for zinc).
>
Sure, I can't disagree with that.
> My current idea is to make dedicated pools that could hold a compile-time
> configurable number of objects of same size, e.g. an IncomingPacketPool
> that can hold up to 3 frames where one frame is 128 bytes long. This way no
> other running process can interfere with code that processes incoming
> packets and that code can offload incoming packets into the pool for later
> processing, but up to three, and it will act in user-defined fashion (drop
> packets) if the pool is full. The implementation of that would be quite
> simple, and I think that it might be possible to extend ~T ownership for
> something like that.
>
I tried playing around[1] (warning: code written by new Rust-er, expect
eye damage, feedback welcome) with a simple buffer pool implementation
this morning; unfortunately I found that Rust's restrictions on function
application in constant expressions makes static allocation quite
difficult (impossible?),
src/lib/pool.rs:47:73: 47:87 error: function calls in constants are limited
to struct and enum constructors
src/lib/pool.rs:47 static pool : Pool<'static, int> = Pool{ entries:
[PoolEntry{ref_count: Unsafe::new(0), value: Unsafe::new(0)}, ..5] };
This despite the fact that the `Unsafe::new` function is underneath just
a constructor application. Perhaps Rust would be well served by a
attribute like C++11's `constexpr`? Perhaps the macro system provides a
workable, if somewhat ugly, solution?
The inability to hide pure constructor applications behind function
calls severely limits the sorts of abstractions one can safely
construct. It seems like this is a worthwhile restriction to lift, even
outside of the embedded context.
Cheers,
- Ben
[1] https://gist.github.com/bgamari/033379d82f179eac8688
pgp_eANyYfY_9.pgp
Description: PGP signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
