Re: MinGW port usable

On Tue, 30 Jan 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Tue, 30 Jan 2007, Daniel Barkalow wrote:
> 
> > On Tue, 30 Jan 2007, Johannes Sixt wrote:
> > 
> > > Daniel Barkalow wrote:
> > > > 
> > > > On Mon, 29 Jan 2007, Johannes Sixt wrote:
> > > > 
> > > > > (*) The reason is that on Windows read() and write() cannot operate on
> > > > > descriptors created by socket(). A work-around is to implement a (threaded)
> > > > > proxy, but that's almost the same as if netcat were used as
> > > > > GIT_PROXY_COMMAND.
> > > > 
> > > > Can you do
> > > > 
> > > > #define read(fd, buffer, len) recv(fd, buffer, len, 0)
> > > > #define write(fd, buffer, len) send(fd, buffer, len, 0)
> > > > 
> > > > in the appropriate file?
> > > 
> > > I doubt that recv and send can operate on regular file descriptors, as
> > > opened by _pipe(), open(), can they?
> > 
> > I don't think so, but I think it should be possible to make 
> > packet_write/packet_read always get a socket, by calling receive-pack and 
> > upload-pack with a socket pair instead of a pair of pipes.
> 
> As I already mentioned in this thread, that would break inetd support.

I was actually thinking of only using recv/send on mingw. So the rule 
could be: if git sets up the connection to a pkt_line-user itself, the 
connection is a socket; otherwise it might be a pair of pipes; if you're 
on mingw, pkt_line uses recv/send. Then everything should work except for 
inetd on mingw, and I don't think that's a plausible combination anyway.

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html