| Age | Commit message (Collapse) | Author |
|---|
|
We're about to add the ability to test with SHA256 hashes. We assume
none of the tests work with this object format.
With this change we add the build constraint to not run any test when
the tag 'gitaly_test_sha256' is set.
|
|
If there has been an error, subsequent calls to Read should keep
returning that error.
Changelog: fixed
|
|
With Go 1.16, the ioutil package was deprecated. Replace our usage of
`ioutil.ReadAll()` with `io.ReadAll()` to adapt accordingly.
|
|
These were set to be removed in v14.
Changelog: removed
|
|
This replaces sendWriter.ReadFrom and receiveReader.WriteTo with
trivial implementations based on io.Copy, to be removed in 14.0.
The purpose of the io.ReaderFrom and io.WriterTo interfaces is to
optimize away a buffer allocation in io.Copy, and/or being able to do
something smart like calling sendfile(2). Without them, io.Copy
allocates a 32KB buffer and reads into / writes from that buffer in a
loop.
The thing is, sendWriter.ReadFrom and receiveReader.WriteTo neither
make a difference for allocations, nor do they do something "smart".
First of all, sendWriter.ReadFrom was not helping the buffer
allocation efficiency because it allocated its own 128KB buffer. In
fact, sendWriter.ReadFrom is equivalent to what io.Copy does on the
inside, so we might as well let io.Copy do that.
That leaves receiveReader.WriteTo as a potentially useful
optimization. It does prevent io.Copy from allocating that 32KB
buffer. However, everytime it calls receiver(), gRPC allocates a new
byte slice anyway, in a loop. Avoiding that one 32KB allocation
outside the loop does not seem worth it.
|
|
The implementation of `Read()` only returns read errors in case no data
is left in the buffer. This is required such that we correctly drain any
buffered data and only return the error when no data is left. This may
not be immediately clear, so this commit puts a comment on this and adds
a testcase which exercises this code path.
|
|
The ReadFrom implementation is quite hard to read as the loop depends on
state from the previous iteration. This commit refactors the code to not
do so anymore by always sending data if we've read something, even if
there was a read error.
|
|
Writing to gRPC streams concurrently isn't allowed, which is why we need
to synchronize those writes. Doing so with the `NewWriter()` is
repetitive, so this commit implements a new function `NewSyncWrite()`
which receives a mutex in addition to the callback function. The mutex
is then locked and unlocked previous to invoking the callback.
|
|
|
|
|
|
|
|
|
