Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:44

Felipe Contreras [off-list ref] writes:
On Mon, Apr 8, 2013 at 1:46 PM, Junio C Hamano [off-list ref] wrote:
quoted
quoted
quoted
...  But if we keep
helper running, who will be communicating with it via these open
pipes?  The process that is calling finish_command() on fast-import
and disconnecting from the helper won't be, as read/write to the
pipe, even if we do not disconnect from here, will result in errors
if the helper has already exited at this point.
Nobody will send any further input, but in theory we could redirect
the pipe and send more commands. That's how it was designed.
Who does the redirection to whom?
The one that is doing all the redirections, transport-helper.
quoted
How would the process tree and
piping constructed around the current system?
I cannot parse that correctly,
Sorry, s/the current system/& look like/;
but transport-helper is already
receiving the output from the remote-helper.
OK, so you are envisioning that transport-helper would read from the
helper after importer is done?  If so, perhaps it is a prudent
solution to disconnect in this version (to fix), and then in a
separate patch that adds such an extension (I imagine it would
involve that the helper advertising a capability or being invoked
with an option to let transport-helper somehow know that it should
continue the conversation once fast-import is done) to disable the
disconnect here when that extension is in use?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help