Yes, exactly. What I am trying to say is that questions about volatile or atomic access are not the core of the issue, it is whether
mmap can actually be used to acquire a
&[u8] to the underlying memory with the guarantees that implies for Rust. It seems that in general it currently cannot. The questions about atomic and volatile are equally valid if it would yield
*const u8 and apply equally to C/C++, but I am interested in that particular extra bit of semantics that Rust adds to the memory reference.
I think that there is also one important difference to using unsafe code and writing to the slice: A completely safe function
use_buf_as_str_and_write_junk_to_file(buf: &[u8], file: File) could show this behavior. And since it cannot know whether
buf is memory-mapped (and it should not need to since all byte slices must have the same properties), getting a byte slice out of mmap in the first place seems to be the problem.
Also since the manual page of mmap actually says
It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.
MAP_PRIVATE, I think
MAP_SNAPSHOT could even be implemented just by sharpening those unspecified semantics. (However, I am not sure if
MAP_PRIVATE would take a performance hit this way which would probably not be acceptable.) I guess I have to try to find someone who is able and willing to make changes to the