From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Fri, 10 Jan 2014 20:11:44 +0000 Subject: RFE: .so filters In-Reply-To: <52D0520C.1070609@xinu.at> References: <20140109225802.GM7608@serenity.lan> <20140110090639.GN7608@serenity.lan> <52D029F9.40805@xinu.at> <52D0520C.1070609@xinu.at> Message-ID: <20140110201144.GQ7608@serenity.lan> On Fri, Jan 10, 2014 at 09:03:24PM +0100, Florian Pritz wrote: > On 10.01.2014 18:57, Jason A. Donenfeld wrote: > > On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote: > >> > >> Isn't this (fast scripting with lots of features) when people normally > >> start using lua? > >> > > > > This would have the same challenges as using .so files, w.r.t. hooking > > write() (or the html functions), but would be very interesting indeed, > > because Lua... > > How about using the current fork approach but instead of calling execvp > use lua. I believe forks are pretty cheap on linux, it's the exec that's > costly. > > If we do it like that we could reuse stdin/stdout, we could pass > arguments via lua tables (like command line arguments now), but we > should have little overhead for the script loading/executing. Forking and using Lua in the child is an interesting idea. I need to investigate how Lua generally deals with I/O, but it feels like it will be simpler to use a simple function interface than deal with slurping in the input in Lua. So it may be simpler to swap out the write function in CGit while the filter is active and collect the output in a buffer instead, then call a Lua function and pass whatever comes back from that to the real write(2).