A few ideas: * make a static P that manages *T storage inside it. *T could be statically pointed to heap block in ram, P will wrap the API to make it less verbose. * use Cell to make internals of immutable mutable back again. This would not work with statics, obviously, as they will land in .rodata, but we have #[link_section] to deal with that. * same as above, but use extern with further linker script placement (same way as I deal with ioregs in zinc).
On Thu, Apr 24, 2014 at 11:37 PM, Ben Gamari <[email protected]> wrote: > Ben Gamari <[email protected]> writes: > > > Vladimir Pouzanov <[email protected]> writes: > > > ... > > >> 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 (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?), > > > Tonight I played around with using the macro system to work around the > static initializer limitation. The result[1] isn't terrible, but > it didn't take long for me to run into a mutability issue. In short, I > was inadvertently declaring my static pool as immutable, causing it to > end up in the data.rel.ro section, resulting in a segfault when I attempt > to increment the reference count (held in an `Unsafe`). > > I thought the obvious way around this would be to declare the pool as > `static mut` but > this unfortunately makes things quite verbose as one must declare each > point of usage as `unsafe`. Moreover, for reasons I don't quite yet > understand it seems that some data is still being placed in a read-only > section and therefore the crash reappears. Regardless, it seems that > mutable statics might be another sticking point in embedded contexts > where static allocation is often desirable. > > Anyone have any clever ideas for dealing with this? > > Cheers, > > - Ben > > > [1] https://gist.github.com/bgamari/033379d82f179eac8688 > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
