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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html