Re: [msysGit] upload-pack timing issue on windows?

On Tue, Aug 24, 2010 at 9:24 PM, Johannes Sixt [off-list ref] wrote:

On Montag, 23. August 2010, Erik Faye-Lund wrote:

quoted

- 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.

OK, thanks for the clarification. Unfortunately, this optimization
breaks down in some cases (like the one I described).

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.

Well, I've found (and supplied patches for) a couple of bugs in it,
but apart from that it seems quite sane. So yeah, I think it might be
the best way forward.

But I'm curious, what's the best way of import a couple of foreign
source files, while maintaining a couple of patches on top of them?
I'm thinking that perhaps a import-commit followed by the patches
would make it easier to merge in changes than to just import the
patched version, but I'm not entirely sure how to do such a merge
without merging a full subtree...