data-race safety

[danburkert]

data-race safety

[danburkert]

@tomjakubowski is exactly right. My current plan is to remove the Deref and DerefMut impls on Mmap and replace it with a pair of methods:

unsafe fn as_slice(&self) -> &[u8];
unsafe fn as_mut_slice(&mut self) -> &[u8];

Additionally, I would like to add support for file locks (even if it is only advisory on POSIX systems) in order to have a runtime check of safety.

[xrl]

What assumptions are broken? Seems fine to me. The mmaps of the same file have different lifetimes and the underlying semantics of how a mmap work are left to the user to consider.

[tomjakubowski]

What assumptions are broken? Seems fine to me. The mmaps of the same file have different lifetimes and the underlying semantics of how a mmap work are left to the user to consider.

The compiler assumes that data behind a &T, where T does not contain UnsafeCell, will not be changed for the lifetime of the reference. It also assumes that a &mut T has exclusive access to its memory. If either of these assumptions are violated, then your program has undefined behavior.

Are data races confined to just shared mmaps, or do anonymous maps expose data races?

A child process can observe writes to shared, anonymous mmaps created by its parent, so I suspect that sticking to anonymous maps isn't sufficient. Maybe anonymous, private mmaps are free from data races.

[danburkert]

I think this issue is fixed. The state of the world is: accessing memory from a Mmap requires an unsafe block, with the invariants clearly marked on the slicing methods (users should ensure that other processes or views are not accessing the memory concurrently). I'm going to punt on file locks, since that is outside the scope of this crate. If someone comes up with a good cross-platform flock interface, this could be used along with the Mmap constructors that take a File for additional runtime safety.