RFE: .so filters

[john at keeping.me.uk (John Keeping)]

On Fri, Jan 10, 2014 at 03:11:54AM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 2:41 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > and does its thing per usual. At the end, however, it does not exit.
> > Instead of waitpid()ing on it in close filter, we SIGSTOP it, put the
> > fds back in place, etc. Then the next time that filter is called, we
> > SIGCONT it, it reads the first N lines as arguments again, and so
> > forth. I'm most tempted to go with this approach at the moment.
> 
> Problems abound. This has race condition issues, where the parent
> process will SIGSTOP the child before the child can write its output.
> This could be fixed with a more complicated signaling protocol, but
> that's more complex than I'd like it. Back to the drawing board.

This seems drastically over complicated.  Why don't we just have
something like this:

    install_filter:
        if filter_running?
            dup2(filter_stdin, STDOUT_FILENO)
        else
            open_filter

    uninstall_filter:
        read until NUL or EOF

Then the filter just sits waiting for data on stdin and we don't need to
stop it at all.  It does complicate things slightly from where we are
because we can't just let the filters writes to stdout go straight to
our (real) stdout but instead we'll have to read data from it.

Annoyingly, although it is probably good enough in this case, we can't
just do the read in uninstall_filter in case we get to a deadlock where
we want to write to the filter but it's waiting for us to read its
output.  I suspect that means we'd need a thread to do the reading and
set a condition variable when it sees NUL or EOF.

I'd rather put that complexity in CGit and make the filter processes
really simple though - it's better to do the complex bit once than many
times!