Am 29.01.2016 um 02:41 schrieb Eric Wong:
Junio C Hamano <gitster@xxxxxxxxx> wrote:
Eric Wong <normalperson@xxxxxxxx> writes:
getaddrinfo() may return multiple addresses, not all of which
are equally performant. In some cases, a user behind a non-IPv6
capable network may get an IPv6 address which stalls connect().
Instead of waiting synchronously for a connect() to timeout, use
non-blocking connect() in parallel and take the first successful
connection.
This may increase network traffic and server load slightly, but
makes the worst-case user experience more bearable when one
lacks permissions to edit /etc/gai.conf to favor IPv4 addresses.
Umm. I am not sure what to think about this change--I generally do
not like a selfish "I'll try to use whatever resource given to me
to make my process go faster, screw the rest of the world" approach
and I cannot decide if this falls into that category.
I'll wait for opinions from others.
No problem, I can also make it cheaper for servers to handle
aborted connections in git-daemon:
standalone:
1) use recv with MSG_PEEK or FIONREAD to determine if there's
readable data in the socket before forking (and avoid
forking for zero-bytes-written connections)
2) use TCP_DEFER_ACCEPT in Linux and dataready filter in FreeBSD
for standalone git-daemon to delay accept()
inetd:
3) suppress die("The remote end hung up unexpectedly")
if no bytes are read at all
At some point in the future, I would love to have git-daemon implement
something like IDLE in IMAP (to avoid having clients poll for updates).
Perhaps the standalone changes above would make sense there, too.
Before you submit a patch in that direction (or resubmit the patch under
discussion here), could you please find someone to test your patch on
Windows first? A lot of the infrastructure mentioned may not be
available there or may not work as expected. (I admit that I'm just
hand-waving, I haven't tested your patch.)
Thanks,
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html