Op 2/11/10 7:25 AM, Teus Benschop schreef:
> 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:
if you're doing all this already in order to facilitate a multi-platform
install ... why not go the extra yard and have the install process setup
a cronjob (or scheduled task, launchd entry, etc, depending on platform)?
> $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);
> }
of itself this seems like reasonable code, people argue about
the finer details but you seem to be writing clean and tidy stuff.
as such I still don't think this kind of thing belongs in a webserver
process.
I have recently been using daemontools (*nix/bsd compatible daemon management
tools ... also used to manage qmail processes) to actually keep a
long running / perpetual script running ... it's a very robust bit of
kit which takes care of running just one instance of whatever
and restarting it if it happens to die ... very nice, very simple, not
available on Windows (AFAIK) ... and helps to keep this kind
of management logic out of the actual php app.
> 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.
I'd think your php is an issue - little bit I've seen suggests you
code diligently, it's merely the vehicle your using to have the script run
perpetually that irks me.
> 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?
in practice not much on a personal machine - nonetheless it's wasteful
and technically a webserver is unneeded and creates another layer of
complexity and overhead. it does seem rather brittle in terms of how you
have it set up though.
realise that your Ubuntu laptop is *probably* alot more stable, robust when
running a never-ending Apache child [worker] process with mod_php loaded and
executing ... I'd be quite confident that it would be stable and such on my
Mac as well ... but a Windows machine, I wouldn't trust that to do it ...
and keep running reliably (not from the script or the user POV)
it's possible that it's the best you can do given the pratical circumstances
of the users/maintainers of the installations ... but I hazard to say
you 'wrapper' for you perpetual/reaccuring script *might* be a sub-optimal
setup ... then again it's rather hard to say without known exactly what you
want done every minute, why it needs to be done on the user's machine and
what the connection with a cloud.
mostly I just curious.
you might also look into HipHop-for-PHP or another PHP code compiler
in order to compile your script to executable machine code which you can
then distribute to users of the software in an install package which
can then setup the relevant cron-type job to run said binary.
>
> Teus.
>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
