in reply to Perlmonks Mush, revisited (Perl as as scripting language)

As we were talking about this on IRC, I mentioned something that I might not have fully explained. In order to avoid the forking overhead, you could instead have one -- or maybe one for each user? The details aren't as important as the concept -- persistant perl executable that is chrooted, secured, etc. You could hand this process various bits of code, which it would then execute and return whatever needs to be returned.

This is all within the realm of standard IPC. You'd have to work out some sort of protocol, consider concurrency issues, etc. I wouldn't be surprised if there are already CPAN modules to take care of some of the work for you, but I don't know of any off the top of my head. This all adds complexity, but the overhead gain may be a net win. You'd have to experiment to be sure.

HTH

  • Comment on Re: Perlmonks Mush, revisited (Perl as as scripting language)

Replies are listed 'Best First'.
Re^2: Perlmonks Mush, revisited (Perl as as scripting language)
by BUU (Prior) on Jun 05, 2004 at 22:35 UTC
    The problem with this is that it would be impossible to impose appropiate rlimits upon this long running process, the cpu limit would kill the stupid thing, so I'm concerned about this "mod_perl" like process using up too many resources on the box.