2000-09-13-13:56:07 John van V:
> 2000-09-12-20:35:32 Bennett Todd:
> > The exact same design targets --- really really fast, teensy
> > memory footprint --- that define the microcontroller embedded
> > market, also define the entry to these roles on the biggest
> > servers.
>
> I'm not sure what that means but I think I like it.
To reprise, "these roles" are settings where fork-n-exec time is
unspeakably important. They occur where you want to do lots and lots
of separate little things, quickly.
One hot one these days is web serving; it's nice to have a juicy
language like perl to write your CGIs in, but it's not nice to have
to fork-n-exec one for each query, nor even to have to have a
separate one (even if preforked) running for every concurrent query,
because perl is so darned big.
Another one is a mail filtering local delivery agent, which needs to
start up and ogle a message and decide what to do with it; it's nice
to have a potent programming language to write such a filter in,
it's not nice having the startup overhead for your filtering program
be decimal orders of magnitude greater than the work required to
deliver a message --- it cuts your email handling capacity in like
proportion.
People come up with hacks to try and let one invocation of the perl
script accomplish more work, to better amortize its cost. mod_perl
is the current prominent standard for CGI, there are other approachs
that try to do the same thing, make the perl persistent (FastCGI and
SpeedyCGI come to mind). An approach I've seen taken for email
filtering is in Mailagent, which adds another spooling system for
re-queueing email in the user's directory, and makes the perl
process persistent so that it can handle multiple messages if they
arrive within a specified time window.
These hacks have the feature that they're complex, and that they
destroy some nice guarantees that the OS is offering in process
isolation; you make perls persistent so that one process can handle
multiple requests, and all of a sudden you're forced to implement
and/or fix a bunch of machinery that's normally not so important, to
achieve necessary isolation between the tasks; memory leaks become
much more important, and you introduce new security worries.
A small, fast language implementation lets you go back to the Good
Old Days where one job was done by one process, and everything got
completely cleaned up on exit at the end of handling the single
task.
-Bennett
PGP signature
