From: Felipe Contreras Date: Tue, 02 Apr 2013 05:19:42 GMT Subject: Re: [PATCH 2/4] transport-helper: check if remote helper is alive Message-ID: In-Reply-To: <20130402050154.GA21328@sigill.intra.peff.net> On Mon, Apr 1, 2013 at 11:01 PM, Jeff King wrote: > On Mon, Apr 01, 2013 at 10:51:20PM -0600, Felipe Contreras wrote: > >> > 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? It's not, I added it for symmetry. But that's the case *if* the remote-helper is properly using the "done" feature. >> 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? I guess that should be possible, I'll give that a try. Cheers. -- Felipe Contreras