|
Re: A Perl Daemon
by merlyn (Sage) on Sep 06, 2005 at 19:47 UTC
|
I think you misunderstand what mod_perl is about, or have not spent a lot of time configuring it properly. The parts of Apache that lead to mod_perl being activated are small and efficient, so "getting rid of Apache" seems an odd goal.
Please make it clearer about why you've ruled out mod_perl. "forking" under mod_perl is no more expensive than forking under your proposed daemon. And you don't "load 3-4mb (sic) of modules every time" you fork under mod_perl. If you preload in the Apache parent process, nothing needs to be loaded per fork.
P.S. 3-4mb is 3 to 4 millibits. That's pretty small. Get 250 to 333 of those together, and you have an entire bit!
| [reply] |
|
|
HA! 3-4 millibits. If all my problems were that small!
While I am not a mod_perl expert I am well versed in it. I understand that forking will not be more expensive and I know that it does not load the modules everytime you fork, that is just silly. And yes getting rid of Apache is my goal here. I would like a Perl daemon. Something that loafs around with precompiled modules sitting in it just waiting to be used by a script that needs them. A kind of module pre-compiler. I want to be able to define which modules I am going to use very frequently have them precompiled, held in a pristine state and ready for use. The only thing close I could think of was mod_perl. Perhaps it was a bad example.
--habit
| [reply] |
|
|
There is PPerl and SpeedyCGI, but really they're about the same as using mod_perl. You haven't provided any reason why mod_perl wouldn't meet your needs here. Maybe if you gave a specific example of how you want to use this, it would become more clear.
| [reply] |
|
|
|
|
|
|
And yes getting rid of Apache is my goal here. I would like a Perl daemon. Something that loafs around with precompiled modules sitting in it just waiting to be used by a script that needs them. A kind of module pre-compiler.
I must say that I have at best and extremely limited experience in this application area, but... I can't understand what your stated goals as in the quotation above could have to do with "getting rid of Apache". That is: once you have your hypothetical perld, do you want to use it to run a webserver written in Perl instead of Apache? If so, then there are some. But I doubt this is what you really want...
| [reply] |
|
|
Re: A Perl Daemon
by tomhukins (Curate) on Sep 06, 2005 at 19:48 UTC
|
Your idea sounds quite close to PPerl. | [reply] |
|
|
Yes that is very close. But not close enough. Unfortunately I do not know what scripts need to be run and so I cannot pre-execute them. Causing all of my scripts to execute with PPerl would probably be a clean-up nightmare I'm afraid.
--habit
| [reply] |
|
|
What do you mean by a cleanup nightmare? Too many daemons running that need to be cleaned up, or your code leaves too many globals around so re-executing in the same process is dangerous?
If you are worried about too many daemons running around, then look at PersistentPerl instead (also called SpeedyCGI). The -g switch will allow you to run all your perl scripts from within the same daemon which will fork off as many child processes as you need. You can also set the child processes to die after a certain amount of inactivity.
If it is your code that you are worried about, then no persistent environment will help you out unless you start off with a fresh interpreter everytime (or cleanup your code).
PersistentPerl comes with an Apache module as well, which means you can save the fork of a CGI process as well when a new request comes in.
| [reply] |
Re: A Perl Daemon
by Tanktalus (Canon) on Sep 06, 2005 at 21:39 UTC
|
This just looks like another approach to solving the same problem as in Doing a standalone executable (and even a binary!). Not without merit, but probably with similar numbers of issues to resolve. Of the two, I'd rather go for the pre-compilation of modules into binary files than a daemon - seems less risky to me.
That said, this idea is at least one you could theoretically do with current technology, while the other idea is one more suited for P5P or Larry to design into P6.
| [reply] |
Re: A Perl Daemon
by samizdat (Vicar) on Sep 08, 2005 at 13:54 UTC
|
I think the question I would raise would be 'Do you want to get rid of http?' Are you intending this perld to be a web app server? If not, then I can understand your idea. Apache handles HTML, SSI, and various script handlers, of which mod_perl is one.
If you are just executing (non-web) perl applications, then forcing perl to remain resident might perhaps be a good idea. However, consider that your operating system and processor are already caching libraries and apps (including Perl) that are executed frequently. If your daemon is not running anything, then it, too, runs the risk of being virtualized into swap space.
I would suggest that you spend some brain cycles considering how your (non-Doze) OS can be your friend. It already has prioritized schedulers, memory management, time-based program execution, and an in-memory daemon called the kernel. :D | [reply] |
Re: A Perl Daemon
by mattr (Curate) on Sep 08, 2005 at 16:23 UTC
|
FWIW I'm working on something with a similar need.
I don't know threads so well and am not sure how well they are implemented on different platforms. I've been looking to choose between POE which apparently can lock up if you get a bug, and other processes forked from it. The root process (which may or may not be a POE app) would hold data shared between children and chase down zombies. I don't know how well garbage collection will work not having used POE before. Is this what's on your mind? | [reply] |
Shared libraries^Wmodules (Was: Re: A Perl Daemon)
by ruoso (Curate) on Sep 09, 2005 at 18:41 UTC
|
One thing that this idea brings is something Java 1.5 implemented... putting the modules in shared memory...
Is there a way to do it?
| [reply] |
Re: A Perl Daemon
by Akhasha (Scribe) on Sep 09, 2005 at 05:44 UTC
|
Actually we've run into similar problems as those habit_forming mentioned (defunct processes, unkillable children(hung on sockets), out of semaphore space errors, etc) when we've tried to fork children from code running under mod_perl. Our testing during development was mostly from the command line and via CGI, then basic checking that it works under mod_perl - which it generally does until its under load, then we get the problems.
The child we were spawning was running a command over ssh that might take a while to complete. I know mod_perl and other persistent Perl environments require a clean lifecycle of the code they run, but are there other requirements for forking code under mod_perl?
| [reply] |
