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

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Jul 7, 2011, 22:37 UTC
Message-ID: <CABPQNSbUx3Z-JCsr1rpjqEvKHSoOLnRP3f7pN6cMfNEiNoZBhg@mail.gmail.com>
In-Reply-To: <20110707222726.GA23424@sigill.intra.peff.net>

On Fri, Jul 8, 2011 at 12:27 AM, Jeff King <peff@peff.net> wrote:

Show 18 quoted lines

> On Fri, Jul 08, 2011 at 12:25:00AM +0200, Erik Faye-Lund wrote:
>
>> On Thu, Jul 7, 2011 at 9:15 PM, Jeff King <peff@peff.net> wrote:
>> > On Thu, Jul 07, 2011 at 01:43:09PM +0200, Erik Faye-Lund wrote:
>> >
>> >> 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 ;)