A vector, like all data in Rust can only be borrowed mutably once at a time, however, if I can guarantee that various slices of this buffer will never interfere with each other, I can guarantee that the multiple-borrow perfectly safe. However, I can't seem to find a valid way to convey this to the Rust compiler. I'm hoping for some advice on how I can do this.
I'm working on a database system which stores information in pages. A page is nothing more than a description of where the data is to be found. A page's contents are scattered over the backing object, in slices of bytes I call chunks. I now need to piece these chunks together to retrieve the information from within the page.
A page must implement AsRef<[u8]> in order to be useful to me, therefore the page's contents must be made contiguous somehow.
Since the backing object is bound by the traits Read + Write + Seek (as in most cases it will be a file), I can allocate a page-sized buffer and pass various slices of the buffer to the Read::read() method in order to populate it.
The backing buffer does not implement Send nor Sync, so all read/write operations are done on a single dedicated worker thread. Pages send various slices of their buffer to this thread in order to do the read/write. My question therefore is, how can I convey to the Rust compiler, that chunks (slices) of the page buffer never interfere with each other, and sending mutable slices to the worker thread is perfectly safe?
They can't be moved. The signature doesn't allow that. The cells to which the return value refere has to be owned somewhere too, but the lifetime means that they can only come from the argument. If thex were moved into the function, a reference to then couldn't be returned.
Because as_slice_of_cells returns each item wrapped in a cell. Each item in this case happens to be a byte. If I have slices of any substantial length, acquiring mutable access to each byte is an absolute waste of resources. Hence I'm searching for a method to lock/restrict slices. I'd considered my buffer to be a vector of vectors, but this again breaks the contiguity guarantee
I don't really get what the problem is here. You can split the returned slice-of-cells just like you would split any other slice. If you think that accessing individual cells would be more expensive than accessing individual bytes, then that's almost certainly not the case due to optimizations.
Please note that T and Cell<T> have exactly the same memory representation, so there's no actual conversion going on. The operation is just a pointer cast that changes the type, and none of the elements in the slice are actually touched by this operation.
I think Cell doesn't help you in your scenario. Cells are not designed for multithreading, Cell isn't Sync, so you can't share a slice of Cells with another thread. They don't seem relevant to your problem.