git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

      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).