On 09/01/14 22:34, Jason A. Donenfeld wrote:
Hey folks, I'm thinking about this filtering situation w.r.t. gravatar and potentially running multiple filters on one page. Something I've been considering is implementing a simple dlopen() mechanism for filters, if the filter filename starts with "soname:" or "lib:" or similar, so as to avoid the fork()ing and exec()ing we currently have, for high frequency filters. The idea is that first use of the filter would be dlopen()'d, but wouldn't be dlclose()'d until the end of the processing. This way the same function could be used over and over again without significant penalty.
In olsrd we have something similar, but there we load the plugins when they are specified in the configuration file.
http://olsr.org/git/?p=olsrd.git;a=summary
In my first thinking of this, the method of action would be the same as the current system -- "int filter_run(int argc, char *argv[])" is dlopen()'d, executed, and it reads and writes to the dup2()'d file descriptor. Unfortunately, the piping in this introduces a cost that I'd rather avoid. In the case of gravatar (or more generally, email author filters), we'd be better off with a "char *filter_run(int argc, char *argv[])", that can just return the string that the html functions will then print. This, however, breaks the current filtering paradigm, and might not be ideal for filters that enjoy a stream of data (such as source code filters). This distinction more or less points toward coming up with a library API of sorts, but I really really really don't want to add a full fledged plugin system. So this has me leaning toward the simpler first idea. But I'm undecided at the moment. Comments and suggestions are most welcome. Jason _______________________________________________ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
-- Ferry Huberts _______________________________________________ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
