x/exp/mmap: should offer access to the mapped byte slice

[AndreKR]

Currently the only way the mapped data is accessible is through the ReadAt(p []byte, off int64) method, which copies from r.data (the mapped area) to p.

I realize that this was probably a deliberate decision, because if it were possible to create further references to the underlying (mapped) array of r.data and those references were accessed after the ReaderAt's Close() method was called, the application would crash.

However, one of the reasons to use mmap is usually performance. In my application I am just copying big chunks of data out of an mmapped area into a pipe. To be honest I have not quantified the impact, but I can imagine that if I could avoid the second copying I could increase the throughput/reduce the CPU load.

Maybe the issue of unsafeness can be addressed by allowing access through a Method named something like UnsafeRawAccess() or something?

The reason why I don't just implement the whole mmapping myself is that the package still offers some value in abstracting the mmap system calls for the different platforms.

[andybons]

@nigeltao

[nigeltao]

Yeah, it's a deliberate decision, so that the mmap.ReaderAt type is always safe to use (from a single goroutine). There's no possibility of a dangling pointer (or dangling slice) even after Close.

If you're copying to a pipe, it might help if the mmap.ReaderAt type also implemented the io.WriterTo interface, and therefore probably io.Seeker too, as WriteTo is associated with a seek offset. That might get the performance gain (if any?? Remember to measure) without breaking API safety.

[AlexanderYastrebov]

void the warranty

func getData(r *mmap.ReaderAt) []byte {
	v := reflect.ValueOf(r)
	f := reflect.Indirect(v).FieldByName("data")
	return f.Bytes()
}