Re: RFC: two minor tweaks to check-ignore to help git-annex assistant

From: Jeff King <peff@peff.net>
Date: Apr 8, 2013, 22:20 UTC
Message-ID: <20130408222059.GA12454@sigill.intra.peff.net>
In-Reply-To: <20130408181311.GA14903@pacific.linksys.moosehall>

On Mon, Apr 08, 2013 at 07:13:11PM +0100, Adam Spiers wrote:

Show 10 quoted lines

> I was recently informed by the author of git-annex that my
> implementation of git check-ignore has two minor deficiencies which
> currently prevent him from adding .gitignore support to the git-annex
> assistant (web UI):
> 
>     1. When accepting a list of files to check via --stdin, no results
>        are calculated until EOF is hit.  This prevents it being used
>        as a persistent background query process which streams results
>        to its caller.  (This is inconsistent with check-attr, which
>        *does* support stream-like behaviour.)

I think flushing on each line is reasonable, though you are also introducing a deadlock possibility for callers which do not read back the output in real-time. For example, if I write N paths out then read N ignore-lines back in, I risk a situation where I am blocked on write() to check-ignore, and it is blocked on write back to me. Somebody has to buffer (the pipe buffers give you some leeway, but they are limited).

Given how new check-ignore is, and that we have not advertised any particular buffering scheme so far, it's probably OK to switch without worrying about breaking existing callers.

But if this is a mode of operation that we expect people to use (here and for check-attr), we should advertise the flushing behavior, and probably warn about the deadlock (I don't think adding a "--no-flush" option is worth it, as it would just mean buffering in check-ignore, which the caller could just as easily do itself).

-Peff