Re: [PATCH 1/1] mingw: optionally disable side-band-64k for transport

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]