Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
AndreKR opened this issue Jun 11, 2017 · 3 comments
Open

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

AndreKR opened this issue Jun 11, 2017 · 3 comments
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@AndreKR
Copy link

AndreKR commented Jun 11, 2017

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.

@gopherbot gopherbot added this to the Unreleased milestone Jun 11, 2017
@andybons andybons changed the title x/exp/mmap should offer access to the mapped byte slice x/exp/mmap: should offer access to the mapped byte slice May 14, 2019
@andybons andybons added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 14, 2019
@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label May 14, 2019
@andybons
Copy link
Member

@nigeltao

@nigeltao
Copy link
Contributor

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
Copy link
Contributor

void the warranty

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

6 participants