All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Eric Wong <normalperson@yhbt.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] attempt connects in parallel for IPv6-capable builds
Date: Fri, 29 Jan 2016 08:10:15 +0100	[thread overview]
Message-ID: <56AB1057.6080700@kdbg.org> (raw)
In-Reply-To: <20160129014106.GA8940@dcvr.yhbt.net>

Am 29.01.2016 um 02:41 schrieb Eric Wong:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Wong <normalperson@yhbt.net> 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

  reply	other threads:[~2016-01-29  7:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 11:57 [PATCH] attempt connects in parallel for IPv6-capable builds Eric Wong
2016-01-28 23:42 ` Junio C Hamano
2016-01-29  1:41   ` Eric Wong
2016-01-29  7:10     ` Johannes Sixt [this message]
2016-01-29  3:04 ` Junio C Hamano
2016-01-29  6:08   ` Torsten Bögershausen
2016-01-30 13:09   ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56AB1057.6080700@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=normalperson@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.