in reply to memory consumption

Instead of sleeping, you may be better off running the script from cron (or whatever they have on Windows). That has the advantage that if the script dies (and you do have a couple of die statements - your program is clearly not written with durability in mind), a minute later, another instance tries again.

As for the memory leak, a classical solution for such daemons is to have them exec() themselves every once in a while. This doesn't work (easily) if the daemon needs to keep state, but your program doesn't. So for instance, you could keep a counter which you increment each loop, and once the counter goes over 500 (or some other number), instead of the goto, you do an exec $0;

Still, I'd go for the crontab solution.

Replies are listed 'Best First'.
Re^2: memory consumption
by afoken (Chancellor) on Jul 07, 2009 at 16:31 UTC

    Some notes:

    Often, it is a bad when two instance of a program run at the same time. So, when you run the script using "scheduled tasks", and this is a problem, check that the current instance is the only instance (which is another common problem).

    Windows has no exec() system call, so that trick won't work on Windows. (Windows also lacks fork(). Another reason to stay away from Windows. ;-) Recent perl versions try to emulate both, but the emulation is far from being complete - simply because Windows has no equivalent of that API calls.)

    exec $0 removes all command line arguments. Often, you don't want that. exec($0,@ARGV) keeps them.

    In any case, exec() removes all context your program had, it literally starts from the beginning. If you need some state information, you have to keep it outside of the process, e.g. in a file or in an environment variable.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      I checked whether the OPs program uses any arguments - he didn't, so exec $0 should be fine. As for context, most context, like environment variables, cwd, and even open file descriptors will be preserved. State information of the process itself of course doesn't, but I already mentioned that. Nor does the OPs program use state information (although the module it uses builds up a state, which causes the memory leak - the state isn't used; the fact the exec loses this state is exactly the reason why exec helps here).

      As for preventing duplicates to be run, something like: 

      use Fcntl ':flock';
open my $me, $0 or die;
flock $me, LOCK_EX|LOCK_NB or exit;

      [download]
      near the beginning of your program usually does the trick.
[reply]
[d/l]

In Section Seekers of Perl Wisdom