data-race safety

[danburkert]

The API exposed by Mmap is not data-race free. For example, if two processes or threads mmap the same file and proceed to read and write, the assumptions Rust makes about &mut [u8] are broken, and the behavior is undefined. It is probably impossible to statically verify that mmap usage is data-race free, however it is against all Rust conventions to expose an API not marked unsafe which can trigger undefined behavior.

Open questions:

• What is the best way to limit the potential unsafety?
• Are data races confined to just shared mmaps, or do anonymous maps expose data races?
• What API changes should be made?

[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]

@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.

[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.