Re: [PATCH 2/4] transport-helper: check if remote helper is alive

From: Jeff King <peff@peff.net>
Date: Apr 2, 2013, 05:01 UTC
Message-ID: <20130402050154.GA21328@sigill.intra.peff.net>
In-Reply-To: <CAMP44s2VcLUE=PHE=iSsgd67_ZV4N6b5Ya76Rc22xtSzK-Xz0g@mail.gmail.com>

On Mon, Apr 01, 2013 at 10:51:20PM -0600, Felipe Contreras wrote:

Show 14 quoted lines

> > So in fetch_with_import, we have a remote-helper, and we have a
> > bidirectional pipe to it. We then call get_importer, which starts
> > fast-import, whose stdin is connected to the stdout of the remote
> > helper. We tell the remote-helper to run the import, then we wait for
> > fast-import to finish (and complain if it fails).
> >
> > Then what? We seem to do some more work, which I think is what causes
> > the errors you see; but should we instead be reaping the helper at this
> > point unconditionally? Its stdout has presumably been flushed out to
> > fast-import; is there anything else for us to get from it besides its
> > exit code?
> 
> The problem is not with import, since fast-import would generally wait
> properly for a 'done' status, the problem is with export.

Your patch modified fetch_with_import. Are you saying that it isn't necessary to do so?

> Also, the design is such that the remote-helper stays alive, even
> after fast-export has finished.

So if we expect to be able to communicate with the remote-helper after fast-export has exited, is it a protocol failure that the helper does not say "yes, I finished the export" or similar? If so, can we fix that?

I am not too familiar with this protocol, but it looks like we read from helper->out right after closing the exporter, to get the ref statuses. Shouldn't we be detecting the error if the helper hangs up there?

-Peff