]> Kevux Git Server - rit/commit
upload-pack: adapt keepalives based on buffering
authorPatrick Steinhardt <ps@pks.im>
Fri, 13 Mar 2026 06:45:13 +0000 (07:45 +0100)
committerJunio C Hamano <gitster@pobox.com>
Fri, 13 Mar 2026 15:54:13 +0000 (08:54 -0700)
commit5d4b7ddce15950ed71ec60453aadfe13d9e633d5
tree8486f3ffbad9591b7b6f6a5af25713c3cc25700a
parent9f4cdf590177eacf8d73f2295c07ad4d4e27ab19
upload-pack: adapt keepalives based on buffering

The function `create_pack_file()` is responsible for sending the
packfile data to the client of git-upload-pack(1). As generating the
bytes may take significant computing resources we also have a mechanism
in place that optionally sends keepalive pktlines in case we haven't
sent out any data.

The keepalive logic is purely based poll(3p): we pass a timeout to that
syscall, and if the call times out we send out the keepalive pktline.
While reasonable, this logic isn't entirely sufficient: even if the call
to poll(3p) ends because we have received data on any of the file
descriptors we may not necessarily send data to the client.

The most important edge case here happens in `relay_pack_data()`. When
we haven't seen the initial "PACK" signature from git-pack-objects(1)
yet we buffer incoming data. So in the worst case, if each of the bytes
of that signature arrive shortly before the configured keepalive
timeout, then we may not send out any data for a time period that is
(almost) four times as long as the configured timeout.

This edge case is rather unlikely to matter in practice. But in a
subsequent commit we're going to adapt our buffering mechanism to become
more aggressive, which makes it more likely that we don't send any data
for an extended amount of time.

Adapt the logic so that instead of using a fixed timeout on every call
to poll(3p), we instead figure out how much time has passed since the
last-sent data.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
upload-pack.c