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

Attachment: pgp1X2kNyfbcq.pgp
Description: PGP signature

_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to