I sort of follow you, but I'm not exactly sure how to implement something like that. How would a cron know by looking at a text file or DB entry when it was supposed to send the mail? Has anyone done anything like this, and are there code samples available somewhere that I can review?
----- Scot Robnett inSite Internet Solutions [EMAIL PROTECTED] -----Original Message----- From: Hanson, Rob [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 1:20 PM To: 'Scot Robnett'; [EMAIL PROTECTED] Subject: RE: Running process in background? Your first solution is prone to memory leaks and your second is just a pain (INHO). > Is there a third alternative? Sure. Create a cron that runs every hour (or less) and checks for scheduled mail to send. All you need to do is have some sort of persistant storage (file or preferably a DB) to store your schedule. Each hour a cron launches your send script which queries the schedule (On Oracle: Select * from schedule where send_time > Sysdate), then iterates through each sending a mail. Rob -----Original Message----- From: Scot Robnett [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 1:50 PM To: [EMAIL PROTECTED] Subject: Running process in background? I'm setting up a mailing subroutine for one of my customers that will send mail based upon a delay of X amount of hours (selected via web form). If I use something like: sub send_on_schedule { my $hours = $q->param('delay'); my $sleeptime = $hours * 3600; # how many seconds? my @addresses = ('[EMAIL PROTECTED]','[EMAIL PROTECTED]'); # from a DB sleep $sleeptime; foreach my $address(@addresses) { some_mail_sending_routine($address); } } then my script/process could technically be running for 24 hours before sending the mail. I want to allow the delay, but I don't think it's a good idea for that process to be running the entire time. I gave some thought to using a cron job, but basically what would have to happen is that in every instance, I'd have to create a crontab, run the cron, then destroy it again. Still, this might be better. Is there a third alternative? Suggestions please? Thanks. ----- Scot Robnett inSite Internet Solutions [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
