On Thu, 2010-02-11 at 06:46 +0000, Jochem Maas wrote:
> Op 2/11/10 6:34 AM, Teus Benschop schreef:
> > On Thu, 2010-02-11 at 05:53 +0000, Jochem Maas wrote:
> >> whatever it is that your trying to do, it sounds like one of two things:
> >>
> >> 1. you have hosting that is unsuitable for your needs
> >> 2. you are tackling the problem incorrectly
> >>
> >> at any rate, as far I'm concerned, you should never have a long running
> >> php process via a web server. (obviously this is the point that someone
> >> posts a brilliant use case to prove me wrong ;-)
> >>
> >> could you detail what is is you're actuallt trying to do, chances are people
> >> have:
> >>
> >> a. got a better alternative
> >> b. already invented the particular wheel you're trying to build
> >> c. you really do need shell (or even just control panel) access to run a cron job
> >>
> >
> > What I am trying to achieve is to have a php script run once a minute
> > and do a few tasks. There are some constraints:
> > - Users usually install the php application on their local machines, be
> > it Linux, Windows, or Macintosh.
> > - The application is defined as needing zero-configuration, i.e. it runs
> > out of the box.
>
> much too vague. no mention of a webserver ... zero-config and needing to install
> are somewhat mutually exclusive.
>
> I still have the feeling you're using the wrong tool for the job somehow,
> I may be wrong or drunk or both ;)
Well, on the web server, this usually would be Apache, though one user
indicated he would use some light httpd instead. Then, of course, yes,
installation is not zero-config, but what I mean is that after
installation no further configuration steps would be needed, e.g. if the
user unpacks a tarball in the web root, it should run straightaway, or
if he does 'apt-get install <pacakge>', no further configuration would
be needed. I thought therefore that using visitors page requests was a
clever way of initiating starting a php script. At the moment I've got
the following code:
$crontable = Database_Cron::getInstance ();
if ($crontable->getFlag ()) die;
$crontable->setFlag ();
ignore_user_abort(true);
set_time_limit(0);
while(1)
{
$log = Database_Logs::getInstance();
$log->log ("Minutely maintenance routine started");
.. do some maintenance ...
$log->log ("Minutely maintenance routine finished");
sleep(60);
}
This uses the mechanism of a sql table in memory, which seems fine for
the moment, since it is volatile and would disappear if the user
restarts his laptop (or if the Amazon cloud reboots ;) - thus next time
the user visits any page, this script would be restarted and do the
maintenance till the user shuts down, and so on. I still have to look
into the other mechanisms of creating a volatile flag.
I think therefore, with my limited experience of PHP, that the above
does well, though improvements are welcome.
About scripts running forever, I don't see a problem here since most of
the time it sleeps anyway, and when I look in my Ubuntu 9.10 laptop,
doing "ps ax" gives 194 live processes already, so what does the one
single extra sleeping process matter?
Teus.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
