@neild @ianlancetaylor

In principle this sounds good but in practice I think this will require exporting some fields from io.SectionReader, or adding at least one new method. And that technically requires a proposal, as described at https://go.dev/s/proposal. Can you look into what an implementation would require? Thanks.

@ianlancetaylor would a linkname-d unexported method be acceptable? That would sidestep the proposal process... (that we can still do if we want, but at least without blocking this)

Honestly I don't think this problem is important enough or urgent enough to reach for go:linkname, which should be avoided whenever possible.

@ianlancetaylor personally I feel the urgency a bit more, but OK, understood.

I don't really have a strong opinion about which way to go for the proposal, and it's not like the rest of package io has relevant examples to copy from for something like this (of the options below, there seem to be a general tendency toward option 1, but it's weak), so maybe you can offer your perspective on which one would be more desirable/in line with expectations:

1. Turn all fields (r, base, off, limit) into exported ones (R, Base, Off, Limit), explaining how to (not) use them
2. Same as 1. but make Offset=0 mean that we're reading from the first byte of the section (in line with Seek(offset, io.SeekStart))
3. Create an Unwrap method (can't find a good name for this one) that returns a copy of all four fields
4. Create Parent() ReaderAt, Base() int64 methods (off and limit can be obtained with a few calls to Seek)
5. Create Parent() ReaderAt, Base() int64, Size() int64 methods (the offset can be obtained with a call to Seek)
6. Create Parent() ReaderAt, Base() int64, Size() int64, Offset() int64 methods
7. Same as one of options 3 to 6, but somehow expose it via an internal/* package (likely a bit of an hack, but would sidestep the proposal)
8. go:linkname shenanigans (even bigger hack, sidesteps the proposal: already excluded, just for completeness)

(all names above are placeholders, feel free to suggest different ones)

Will take your preference and prepare the proposal based on it.

I don't see a problem with exporting the r and base fields. And then as you say we can get the current offset and the final offset using Seek, so maybe that is enough.

@CAFxX Discussion in #61530 might be related and interesting to you.

Change https://go.dev/cl/526855 mentions this issue: io: add (*SectionReader).Outer()

Early results for sending a 1MB file:

goos: linux
goarch: amd64
pkg: test
cpu: Intel(R) Xeon(R) CPU @ 2.20GHz
        │ master.txt  │              patch.txt              │
        │   sec/op    │   sec/op     vs base                │
Serve-4   466.5µ ± 3%   268.5µ ± 5%  -42.43% (p=0.000 n=10)

        │  master.txt   │               patch.txt               │
        │     B/op      │     B/op       vs base                │
Serve-4   52.331Ki ± 3%   8.423Ki ± 26%  -83.90% (p=0.000 n=10)

        │ master.txt  │              patch.txt              │
        │  allocs/op  │  allocs/op   vs base                │
Serve-4   152.00 ± 7%   87.50 ± 10%  -42.43% (p=0.000 n=10)

master...CAFxX:go:cafxx-sendfile-sectionreader

Change https://go.dev/cl/527215 mentions this issue: net: support sendfile for SectionReader (linux)