[ previous ] [ next ] [ threads ]
 From:  Kris Maglione <bsdaemon at comcast dot net>
 To:  Chris Buechler <cbuechler at gmail dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] The future - summary
 Date:  Fri, 14 Oct 2005 00:31:35 -0400
Chris Buechler wrote:

>Problem is, if it's going to run all the time, it's going to have to
>be light weight enough that it doesn't tie up significant resources,
>especially CPU.  Again, with limited resources we're working with, we
>really have to watch this.
I definately agree that this takes PHP out of the question, but only
because it would have to fork, rather than thread. Perl, in my
experience, isn't the memory hog that it's made out to be. Webmin, for
instance, on my system (I don't know why I have it running, since I
don't use it, but...) takes up roughly 5MB reserved and is using less
than 4 of that. It doesn't even get up to 5 when it's handling a
request. I imagine that Python and Ruby have similar footprints
(although I've got portupgrade running right now, and it's ruby
interperater's using over 25MB). Even the small JVMs, on the other hand,
get huge fast. I think that Kaffe may actually be worse than the big guys.

Also, there's the option of a hybrid approach to consider. There could
be a C/C++ core that listens on a socket, sleeps, etc, and spawns an
interperater when necessary. I think, though, that the overhead would't
be worthwhile, especially if it winds up being called often. I just want
to mention it, since it's similar to the way that the http daemon works.

It might be interesting to see some real world examples of the
Perl/Python/Ruby interperaters running in such situations (as
stand-alone daemons, that is). If they're light weight enough, and clean
up after themselves (i.e. don't keep too much resident data hanging
around), then I think that the idea's feasable.