Hello there.

I have a project, where I need to upload different files via sftp and I use concurrent reads/writes with config:

sftpCl, err := sftp.NewClient(
	sshConn,
	sftp.UseConcurrentReads(true),
	sftp.UseConcurrentWrites(true),
	sftp.MaxConcurrentRequestsPerFile(64),
	sftp.MaxPacket(32768), // Max possible number per packet.
)

In addition, I need graceful shutdown thus, I wrapped my file reader with context:

type ReaderWithContext struct {
	ctx context.Context
	r   io.Reader
}

func (r *ReaderWithContext) Read(p []byte) (int, error) {
	if err := r.ctx.Err(); err != nil {
		return 0, err
	}

	return r.r.Read(p)
}

But I noticed a huge regression in speed, where my test data ~15MB was uploading >1 min compare to ~12 sec without custom interface. After debugging, I found out that the actual problem was inside the ReadFrom function, since it defines remain but only if io.Reader implements Len(), Size(), Stat() or it is an io.LimitedReader. In other cases it starts read/write without concurrency. I assume it is the way to avoid situations when remain is 0 and signalise of io.EOF or reader errors. So, we perform single Read, to define this and not to start all the routines for concurrent read/writes.

I can solve my situation with explicit call to ReadFromWithConcurrency or wrap my context reader with io.LimitedReader.
But maybe there can be an addition to ReadFrom func docs, which explain/warn about this specific behaviour? Or cover situation when remain is 0 with an attempt to call ReadFromWithConcurrency anyway?