Junio C Hamano <[email protected]> wrote:
> Eric Wong <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
