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).
> @@ -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:
> @@ -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).
> @@ -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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html