On Montag, 23. August 2010, Erik Faye-Lund wrote: > - The culprit seems to be our poll-emulation. My understanding is that > poll() was called by create_pack_file() in upload-pack.c with nfds=1 > (it's 2 until one of the fds are closed) when there's no data > available in the pipe. Since our poll() always returns POLLIN when > nfds=1, the check for xread(...) == 0 further down in > create_pack_file() cause the fd to be closed, leading to an error on > the client-side. > - Just removing the nfds=1-hack works for me, but I'm suspecting the > nfds=1-hack is there for some socket-reason. So instead I've replaced > our poll-emulation with gnulib's in my branch (with a couple of > patches on top), and it seems to do the trick for me. I still haven't > tested it heavily, though. The nfds == 1 hack is an "optimization": When only one channel must be observed, then we can let (x)read() wait for data instead of doing it inside poll() in some way. I'm not happy with our poll emulation because it contains a busy-loop. Gnulib's version looks quite capable, but I haven't studied it in detail. Until then, I trust that it does the right thing. --Hannes -- 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