Re: [PATCH 05/16] fsmonitor--daemon: refactor cookie handling for readability

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Mar 11 2022, Jeff Hostetler via GitGitGadget wrote:

> From: Jeff Hostetler <jeffhost@microsoft.com>
>
> fixup! fsmonitor--daemon: use a cookie file to sync with file system
>
> Use implicit definitions for FCIR_ enum values.
>
> Remove const from cookie->name.
>
> Reverse if then and else branches around open() to ease readability.
>
> Document that we don't care about errors from close() and unlink().
>
> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
> ---
>  builtin/fsmonitor--daemon.c | 53 +++++++++++++++++++++----------------
>  1 file changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
> index 97ca2a356e5..02a99ce98a2 100644
> --- a/builtin/fsmonitor--daemon.c
> +++ b/builtin/fsmonitor--daemon.c
> @@ -109,14 +109,14 @@ static int do_as_client__status(void)
>  
>  enum fsmonitor_cookie_item_result {
>  	FCIR_ERROR = -1, /* could not create cookie file ? */
> -	FCIR_INIT = 0,
> +	FCIR_INIT,
>  	FCIR_SEEN,
>  	FCIR_ABORT,
>  };
>  
>  struct fsmonitor_cookie_item {
>  	struct hashmap_entry entry;
> -	const char *name;
> +	char *name;
>  	enum fsmonitor_cookie_item_result result;
>  };
>  
> @@ -166,37 +166,44 @@ static enum fsmonitor_cookie_item_result with_lock__wait_for_cookie(
>  	 * that the listener thread has seen it.
>  	 */
>  	fd = open(cookie_pathname.buf, O_WRONLY | O_CREAT | O_EXCL, 0600);
> -	if (fd >= 0) {
> -		close(fd);
> -		unlink(cookie_pathname.buf);
> -
> -		/*
> -		 * Technically, this is an infinite wait (well, unless another
> -		 * thread sends us an abort).  I'd like to change this to
> -		 * use `pthread_cond_timedwait()` and return an error/timeout
> -		 * and let the caller do the trivial response thing, but we
> -		 * don't have that routine in our thread-utils.
> -		 *
> -		 * After extensive beta testing I'm not really worried about
> -		 * this.  Also note that the above open() and unlink() calls
> -		 * will cause at least two FS events on that path, so the odds
> -		 * of getting stuck are pretty slim.
> -		 */
> -		while (cookie->result == FCIR_INIT)
> -			pthread_cond_wait(&state->cookies_cond,
> -					  &state->main_lock);
> -	} else {
> +	if (fd < 0) {
>  		error_errno(_("could not create fsmonitor cookie '%s'"),
>  			    cookie->name);
>  
>  		cookie->result = FCIR_ERROR;
> +		goto done;
>  	}
>  
> +	/*
> +	 * Technically, close() and unlink() can fail, but we don't
> +	 * care here.  We only created the file to trigger a watch
> +	 * event from the FS to know that when we're up to date.
> +	 */
> +	close(fd);

It still seems odd to explicitly want to ignore close() return values.

I realize that we do in (too many) existing places, but why wouldn't we
want to e.g. catch an I/O error here early?