From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Fri, 10 Jan 2014 09:06:39 +0000 Subject: RFE: .so filters In-Reply-To: References: <20140109225802.GM7608@serenity.lan> Message-ID: <20140110090639.GN7608@serenity.lan> 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 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!