From: Jason at zx2c4.com (Jason A. Donenfeld)
Subject: RFE: .so filters
Date: Thu, 9 Jan 2014 22:34:26 +0100 [thread overview]
Message-ID: <CAHmME9p6nE36-4PWxZTvSdZ0=mUu0CGBh4aRkr3KBaeiNH8reg@mail.gmail.com> (raw)
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 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
next reply other threads:[~2014-01-09 21:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 21:34 Jason [this message]
2014-01-09 22:29 ` mailings
2014-01-09 22:58 ` john
2014-01-10 1:41 ` Jason
2014-01-10 2:11 ` Jason
2014-01-10 4:26 ` Jason
2014-01-10 9:06 ` john
2014-01-10 15:57 ` Jason
2014-01-10 17:12 ` bluewind
2014-01-10 17:20 ` john
2014-01-10 17:43 ` mricon
2014-01-10 18:00 ` Jason
2014-01-10 18:00 ` Jason
2014-01-10 17:57 ` Jason
2014-01-10 20:03 ` bluewind
2014-01-10 20:11 ` john
2014-01-10 20:25 ` bluewind
2014-01-10 20:36 ` john
2014-01-10 20:56 ` bluewind
2014-01-11 2:37 ` Jason
2014-01-11 2:34 ` Jason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHmME9p6nE36-4PWxZTvSdZ0=mUu0CGBh4aRkr3KBaeiNH8reg@mail.gmail.com' \
--to=cgit@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).