From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Thomas Braun via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Thomas Braun <thomas.braun@byte-physics.de>
Subject: Re: [PATCH 1/1] mingw: optionally disable side-band-64k for transport
Date: Tue, 30 Apr 2019 18:37:06 -0400 (DST) [thread overview]
Message-ID: <nycvar.QRO.7.76.6.1904301834230.45@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20190429231928.GQ6316@genre.crustytoothpaste.net>
Hi brian,
On Mon, 29 Apr 2019, brian m. carlson wrote:
> On Mon, Apr 29, 2019 at 03:04:36PM -0700, Thomas Braun via GitGitGadget wrote:
> > From: Thomas Braun <thomas.braun@byte-physics.de>
> >
> > Since commit 0c499ea60f (send-pack: demultiplex a sideband stream with
> > status data, 2010-02-05) the built-in send-pack uses the side-band-64k
> > capability if advertised by the server.
> >
> > Unfortunately this breaks pushing over the dump git protocol if used
> > over a network connection when using MinGW (but *not* when using
> > mingw-w64).
> >
> > The detailed reasons for this, are courtesy of Jeff Preshing, quoted
> > from https://groups.google.com/d/msg/msysgit/at8D7J-h7mw/eaLujILGUWoJ:
> >
> > MinGW wraps Windows sockets in CRT file descriptors in order to
> > mimic the functionality of POSIX sockets. This causes msvcrt.dll
> > to treat sockets as Installable File System (IFS) handles,
> > calling ReadFile, WriteFile, DuplicateHandle and CloseHandle on
> > them. This approach works well in simple cases on recent
> > versions of Windows, but does not support all usage patterns.
> > In particular, using this approach, any attempt to read & write
> > concurrently on the same socket (from one or more processes)
> > will deadlock in a scenario where the read waits for a response
> > from the server which is only invoked after the write. This is
> > what send_pack currently attempts to do in the use_sideband
> > codepath.
>
> Since this is a platform-specific issue, can we address this using a
> compile-time constant instead of a config option? It would be better to
> do the right thing automatically in this case and not have to have
> people set a config option. It will also allow us to not to have to
> maintain a config option indefinitely if MinGW becomes more capable in
> the future.
I was really not sure at the time whether this would be fixed in MinGW at
some stage, and with the switch to mingw-w64 (by moving from MSys to MSYS2
as of Git for Windows 2.x) we do not really have any concrete need for it
anymore.
I just thought that it might benefit somebody (it was my impression that
Hannes Sixt still built his own copy with MSys/MinGW, and we do have a
track record of maintaining certain things even for single users, see e.g.
our insistence on creating the .git/branches/ directory upon `git init`).
But if the consensus is that we do not need this at all anymore, I'll be
just as happy to drop that patch.
Ciao,
Dscho
prev parent reply other threads:[~2019-04-30 22:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 22:04 [PATCH 0/1] Support git:// with old MinGW Johannes Schindelin via GitGitGadget
2019-04-29 22:04 ` [PATCH 1/1] mingw: optionally disable side-band-64k for transport Thomas Braun via GitGitGadget
2019-04-29 22:10 ` Eric Sunshine
2019-04-29 23:17 ` Johannes Schindelin
2019-04-30 6:21 ` Johannes Sixt
2019-04-30 22:33 ` Johannes Schindelin
2019-04-30 22:55 ` Johannes Sixt
2019-05-03 8:42 ` Johannes Schindelin
2019-04-29 23:19 ` brian m. carlson
2019-04-30 22:37 ` Johannes Schindelin [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.QRO.7.76.6.1904301834230.45@tvgsbejvaqbjf.bet \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
--cc=thomas.braun@byte-physics.de \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).