Re: [PATCH/RFC 3/3] upload-archive: use start_command instead of fork

On Fri, Jul 8, 2011 at 12:27 AM, Jeff King [off-list ref] wrote:

On Fri, Jul 08, 2011 at 12:25:00AM +0200, Erik Faye-Lund wrote:

quoted

On Thu, Jul 7, 2011 at 9:15 PM, Jeff King [off-list ref] wrote:

quoted

On Thu, Jul 07, 2011 at 01:43:09PM +0200, Erik Faye-Lund wrote:

quoted

The POSIX-function fork is not supported on Windows. Use our
start_command API instead.

Is start_command the right solution? From my reading, the fork is
actually because we want to set up a sideband multiplexer. Should we not
just be using start_async() to start a thread, as we do in receive-pack?

I considered that, but discarded it because I figured it required me
to plug through a file descriptor all the way through the code. But
perhaps I was wrong, and dup2 will make that job a lot easier?

Yeah, exactly. The current code is already using dup2 in the same way.

It does, but I'm not entirely sure how dup2 works when start_async is
implemented with threads. Won't cause the multiplexer to fail (the
multiplexer and the archive-thread needs different stdouts), because
file descriptors are process-resources, and not thread-resources?

I guess I could dup stdout/stderr before dup2'ing, and have the
multiplexer write to explicitly to the duped fds. It's starting to
sound very confusing to my ears, but perhaps it's the best option
still ;)