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 · 2 comments
Open

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

AndreKR opened this issue Jun 11, 2017 · 2 comments

Comments

@AndreKR
Copy link

@AndreKR 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
Copy link
Member

@andybons andybons commented May 14, 2019

Loading

@nigeltao
Copy link
Contributor

@nigeltao nigeltao commented May 15, 2019

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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants