Re: Perl Daemons

Perl does return memory to the OS, just not all of it all the time. :-)

Anyway, I'd go for the solution the apache webserver uses: run a really simple controlling process, that fork()s off children to do the real work, and kill them after handling a certain number of requests. That way, you only have to worry about bloat in the controlling program. In fact, you can even use code in the children that you KNOW are not safe in the long run.

update: typo fixed ("the solution")

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re: Perl Daemons

Replies are listed 'Best First'.
Re^2: Perl Daemons by pbeckingham (Parson) on Jul 28, 2004 at 18:57 UTC
I agree with you - essentially the program doing the real work has to exit periodically, or every time. The controller can often be reduced to a shell script, where the shell itself we assume is not suffering from the same problem.	[reply]
Re^3: Perl Daemons by diotalevi (Canon) on Jul 28, 2004 at 19:18 UTC
Perlmonks' streaming ticker periodically execs itself which is a variant on the same theme. Instead of forking off children to do work, the main POE process does all of the work and avoids such problems by restarting itself.	[reply]
Re^3: Perl Daemons by Joost (Canon) on Jul 28, 2004 at 19:06 UTC
I don't think the controller needs to be a shell script, in fact, I think that in a perl script it might be easier to control the memory usage (just a hunch). I think that as long as you don't create and destroy loads of lexicals in the controller, you should be alright. Ofcourse, if you have a simple controller, it should be easy enough to test for leaks - just do a couple of million iterations though the controller's mainloop without running the childs. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]