[ previous ] [ next ] [ threads ]
 From:  Jim Thompson <jim at netgate dot com>
 To:  Kris Maglione <bsdaemon at comcast dot net>
 Cc:  Chris Buechler <cbuechler at gmail dot com>, m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] The future - summary
 Date:  Thu, 13 Oct 2005 21:10:14 -1000
On Oct 13, 2005, at 6:31 PM, Kris Maglione wrote:

> 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.

which doesn't explain why people are able to run JVMs in cell phones  
with less memory
than the cache on your machine.

> 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.

It could keep an interpreter open (spawned) and send commands to  
it.   This would
make several things easier, including the time-based stuff.

Also, no need to fork per-request or thread, we've known how to use  
select() (and poll()) for a long time.

> 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.

perl/python/ruby tend to be fairly small, until you start loading all  
the libraries that make them so nice to play with.

one advantage of these three over PHP is that they are all garbage- 
collected (though the GC in perl tends to be a bit ... weak.)