in reply to Exec'd perl running wild on cpu-time

Your main loop offers no clues at all as to the CPU problem. Have you tried using strict and running Perl with warnings (-w) enabled?

Note that your filter_data function is being called twice: once for write_data and once for mail_data. If this is an expensive function you should consider running it once, storing the results, and pass those results to each of the two functions.

If your main functions are too long to post, consider just reading through them and check your assumptions and error checking. What happens if it can't get a response? What happens if the response it gets doesn't follow your expectations? Are you looping and using a variable to determine when the loop should end? If so, are you sure this variable is allowing the loop to exit when unexpected things happen?

In the past, I've occasionally used 'strace' (or 'truss' or 'ptrace', depending on your OS) against a process stuck like that. That usually lets me see what system calls it's trying to do (if any). Sometimes this points me to the right place in my code.

Replies are listed 'Best First'.
RE: Re: Exec'd perl running wild on cpu-time
by jeroenes (Priest) on Nov 13, 2000 at 20:11 UTC
    Quite a few remarks... thank you! 1. No warnings. I still haven't looked into the module programming, so I don't know what to do with the 'import' stuff. Has been moved into my 'todo' list....

    2. Indeed, the function is called twice. Normally, CPU time is no issue, it's only two minutes/day MAX. And I think most time is spend waiting for the HTML content.

    3. If any connection or whatever fails, the script is simply terminated with a die. No problems from that perspective (ie, a terminated script) thusfar.

    4. If a content is not matched, the filter just returns an empty array, and only the 'templates' ar logged/mailed. The filter routine, and the parse routine are quite simple, just some coupled regex's that fill some arrays. If something goes wrong, an array will be empty, that's all. If a connection fails, the script will die().

    5. see next answer

    Jeroen

    I was dreaming of guitarnotes that would irritate an executive kind of guy (FZ)

[reply]
      Another thing I would recommend is setting yourself up with a debugging log. Have it log the last few (or all) of its requests and the results it gets back from the server. The next time your script misbehaves, take a look at this log to see what it's acting upon. If you want to put 'markers' or 'checkpoints' in various places in and around your loops, so that information is logged as your program reaches various points of execution, this would also let you trace the flow of execution, though if your script is entering an infinite loop (which I suspect it is), this log file will fill up fast.
[reply]

In Section Seekers of Perl Wisdom