All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: git@vger.kernel.org
Subject: Re: [updated patch v2 1/2] Report exec errors from run-command
Date: Thu, 31 Dec 2009 17:22:02 +0100	[thread overview]
Message-ID: <4B3CCFAA.7060702@kdbg.org> (raw)
In-Reply-To: <1262256488-22985-2-git-send-email-ilari.liusvaara@elisanet.fi>

Ilari Liusvaara schrieb:
> +static inline void force_close(int fd)
> +{
> +	int err = 0;
> +	/*
> +	 * Retry EINTRs undefinitely, exit on EBADF immediately, other
> +	 * errors retry only up to three times (even if pipe close
> +	 * shouldn't cause other errors, but you never know with
> +	 * what broken systems may return on closed file descriptor).
> +	 * consequences of failure to close pipe here may include
> +	 * deadlocking.
> +	 */
> +	while (close(fd) < 0 && errno != EBADF && err < 3)
> +		if(errno != EINTR)
> +			err++;

What's the point to iterate on all errors except EBADF? If the close() 
fails once, it will fail again.

> +			/*
> +			 * Clean up the process that did the failed execution
> +			 * so no zombies remain.
> +			 */
> +wait_again:
> +			r = waitpid(cmd->pid, &ret, 0);
> +			if (r < 0 && errno != ECHILD)
> +				goto wait_again;

You really should iterate only on well-known errors. What's wrong with

		while (waitpid(pid, &status, 0) < 0 && errno == EINTR)
			;	/* nothing */

similar to wait_or_whine()'s call to waitpid() and to avoid goto.

> +int main(int argc, char **argv)
> +{
> +	char* procs[2];
> +	struct child_process proc;
> +	memset(&proc, 0, sizeof(proc));
> +
> +	if(argc < 2)
> +		return 1;
> +
> +	if (argv[1][1] == '1')
> +		procs[0] = "does-not-exist-62896869286";
> +	procs[1] = NULL;
> +	proc.argv = (const char **)procs;
> +
> +	if (!run_command(&proc))
> +		return 1;
> +	if (errno != ENOENT)
> +		return 1;
> +	return 0;
> +}

This test is not specific enough: It would pass even without your change 
to start_command(), because finish_command() detects the ENOENT case. You 
really want to test that you see ENOENT after start_command() (i.e., 
before finish_command()).

-- Hannes

  reply	other threads:[~2009-12-31 16:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-31 10:48 [updated patch v2 0/2] Improve remote helper exec failure reporting Ilari Liusvaara
2009-12-31 10:48 ` [updated patch v2 1/2] Report exec errors from run-command Ilari Liusvaara
2009-12-31 16:22   ` Johannes Sixt [this message]
2009-12-31 10:48 ` [updated patch v2 2/2] Improve transport helper exec failure reporting Ilari Liusvaara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B3CCFAA.7060702@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=ilari.liusvaara@elisanet.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.