Re: [PATCH v3 0/3] packfile URIs: support concurrent downloads

On Sat, Jul 25, 2026 at 05:21:54AM -0400, Jeff King wrote:

On Sat, Jul 25, 2026 at 05:09:11AM -0400, Jeff King wrote:

quoted

So from the perspective of the server process, everything is fine, but
curl complains that it didn't get all of the bytes. Weird. The strace
shows both writing the first 1MB as expected. It's like the connection
gets hung up for some reason, but I can't tell why or by whom.

Hmph. I tried stracing on the client side, and we indeed see an EOF
on the socket:

  recvfrom(12, "", 16384, 0, NULL, NULL) = 0

I'm really puzzled why that is the case, though, as the server side did
not close() or exit.

So I'm still puzzled by all of this, but I think it's mostly a red
herring with respect to the actual "test -s" race.

The server tells us when it has written the first 1MB to the client, and
then we check that "test -s" is showing something in the on-disk
tempfile we're downloading.  But there's no guarantee that just because
the server called write() that client has yet received the data, let
alone written it to disk.

I can't think of a synchronization point we could use here. We're
waiting on curl to have passed the bytes to fwrite() and for it to have
actually synced to disk. We either have to poll or modify http.c to
write "yes, we got some bytes!" to a fifo. Both are pretty gross.

I wonder if we could just drop that "test -s" entirely. We'd _usually_
see some bytes written before the second request starts. But it's OK if
we don't. It just means the test is working in the reverse order (the
second request may write its bytes first, and then the first one is the
one "overwriting" it). I.e., the two are symmetric from our perspective.

-Peff