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

Re: [RFC 4/4] Add cat-blob report pipe from fast-import to remote-helper.

From: Jeff King <hidden>
Date: 2016-06-15 22:53:59

On Mon, Jun 04, 2012 at 07:20:55PM +0200, Florian Achleitner wrote:
On invocation of a helper a new pipe is opened.
To close the other end after fork, the prexec_cb feature
of the run_command api is used.
If the helper is not used with fast-import later the pipe
is unused.
The FD is passed to the remote-helper via it's environment,
helpers that don't use fast-import can simply ignore it.
fast-import has an argv for that.
I don't keep up on fast-import development, so I have no clue how useful
this extra pipe is, or whether this patch is a good idea overall. But a
few comments on the transport.c half of things:
+static int fd_to_close;
+void close_fd_prexec_cb(void)
+{
+	if(debug)
+		fprintf(stderr, "close_fd_prexec_cb closing %d\n", fd_to_close);
+	close(fd_to_close);
+}
Note that preexec_cb does not work at all on Windows, as it assumes a
forking model (rather than a spawn, which leaves no room to execute
arbitrary code in the child). If all you want to do is open an extra
pipe, then probably run-command should be extended to handle this
(though I have no idea how complex that would be for the Windows side of
things, it is at least _possible_, as opposed to preexec_cb, which will
never be possible).
quoted hunk ↗ jump to hunk
@@ -376,13 +411,20 @@ static int fetch_with_fetch(struct transport *transport,
 static int get_importer(struct transport *transport, struct child_process *fastimport)
 {
 	struct child_process *helper = get_helper(transport);
+	struct helper_data *data = transport->data;
+	struct strbuf buf = STRBUF_INIT;
 	memset(fastimport, 0, sizeof(*fastimport));
 	fastimport->in = helper->out;
 	fastimport->argv = xcalloc(5, sizeof(*fastimport->argv));
 	fastimport->argv[0] = "fast-import";
 	fastimport->argv[1] = "--quiet";
+	strbuf_addf(&buf, "--cat-blob-fd=%d", data->fast_import_backchannel_pipe[1]);
+	fastimport->argv[2] = strbuf_detach(&buf, NULL);
Consider converting this to use argv_array. You can drop the magic
numbers, and "argv_array_pushf" handles the strbuf bits for you
automatically.

And this grossness can go away:
quoted hunk ↗ jump to hunk
@@ -441,6 +488,7 @@ static int fetch_with_import(struct transport *transport,
 
 	if (finish_command(&fastimport))
 		die("Error while running fast-import");
+	free((void*)fastimport.argv[2]);
 	free(fastimport.argv);
 	fastimport.argv = NULL;
(you'd instead want to free everything; it would probably make sense to
add an argv_array_free_detached() function to do so).
quoted hunk ↗ jump to hunk
@@ -427,6 +469,11 @@ static int fetch_with_import(struct transport *transport,
 	if (get_importer(transport, &fastimport))
 		die("Couldn't run fast-import");
 
+
+	/* in the parent process we close both pipe ends. */
+	close(data->fast_import_backchannel_pipe[0]);
+	close(data->fast_import_backchannel_pipe[1]);
I'm confused. We close both ends? Who is actually reading and writing to
this pipe, then?

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help