Doc for func (a *reader) Close() says that a.in should be closed, but there is no call to Close() on it anywhere.

Hello,

In case the underlying io.Reader panics, the host program will enter an unrecoverable state.

Would you consider adding an option to allow recovery of a panic?

I wonder, would this be useful for a case like:

Input: Partial downloads of say 16K chunks every iteration
ReadAhead: Buffers, say 32K chunks (or any configurable size)
xml.Decoder: Consumes the buffers to populate a struct.

Thanks.

I think that if reader.Close is not called, this line will block indefinitely, causing a memory "leak" of the struct and its buffers:

https://github.com/klauspost/readahead/blob/master/reader.go#L100-L102

100:			case <-a.exit:
101:				return
102:			}

once an error has been returned from the Reader, it will not recover

In that case, why not just close a.exit when Read returns any error?

Hi!

I'm currently seeing that reads are blocking until a buffer is completely full. This doesn't fit well with my use case—mocking a TLS handshake over connections from net.Pipe—most reads will never fill an entire buffer, and the interleaving reads and writes of the handshake protocol mean that a read failing to immediately return deadlocks the connection. This behavior seems expected as a result of #16, however this is directly contradictory to the article introducing the library:

Finally, there is the case where the input reader does not deliver as many bytes as we request. That is fairly common, and can indicate a lot of things. But to keep input->output latency at a minimum we forward this to output at once, even though you might have requested bigger buffers.

I have resorted to one-byte buffers to make this work; I obviously know this is less than ideal and that performance is suffering as a result, however it does now fulfill the package's goal. Is this behavior intended, and if so, is there any other workaround that you can see without knowing a minimum read size?