My problem: In writing a memory-mapped file API, I'd like to expose the mapped memory as a vec[u8] in Rust. I could make another kind of object wrapper, but in the interest of having interoperable code, I think having all byte vectors be vec[u8] would be preferable. The rust_vec type in the runtime however, expects its data vector to be inside of the struct itself. Copying a memory-mapped file into a struct isn't quite what we want.
My proposed solution: Add a pointer to the rust_vec struct that points at the data. For normal vectors, it'll just point at the data section inside the struct, but we'll add a way to allocate a vector that takes some external byte array and wraps it as a vec. Upsides: - The added indirection is so minor that I don't expect there'll be a noticeable peformance change. - We'll need this in other places too, if we want efficient system's stuff programmed in Rust Downsides: - Vec structs, and thus strings, become bigger. - The creator of such a vec will be responsible for cleaning up the byte array at the appropriate time. If the vec 'escapes', doing this reliable becomes very hard. We could (at the cost of more complexity and probably size) make it so that a custom deallocator is called when the vec is finalized. A possible alternative: Provide a vec-like API around byte vbufs. We'd have two different byte array representations, which will result in some code duplication and questions of which to use when, and it doesn't really help safety much. But it will make it clear when you're working with rust-curated memory and when you're handling raw undomesticated could-be-anything data. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
