On Mon, Apr 29, 2019 at 03:04:36PM -0700, Thomas Braun via GitGitGadget wrote: > From: Thomas Braun <[email protected]> > > 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
signature.asc
Description: PGP signature
