cotonti.com : CRON Engine https://www.cotonti.com Последние сообщения в теме Cotonti en Mon, 20 Oct 2025 02:49:46 -0000 Mynt
I agree, which re-iterates my first statement of, I don't see a need for a crontab at all. Though, instead of a cron, maybe a simple UI that just says every month, HEY BACK UP, HEY RESYNCH, HEY DO THIS.]]>
ср, 19 авг 2009 06:47:54 -0000
Kilandor
I can assure you that any sort of cron that works based off user's accessing a website is not good and does not always work correctly.

It very easily can run multiple times, I know this for a fact of how we used to run my Ticket/Revision bot, it was using a hook, that was time based and often was executed multiple times, even implementing a file locking method it was still getting ran multiple times. So no such solution can work perfect, and duplicate exectuions will happen.

As well as most typical users won't need a cron period anyways.]]>
вт, 18 авг 2009 18:34:55 -0000
Mynt # Trustmaster : That would work if you get less than 600 hits. If you get more than 60000 that would be better to use cron instead. Both would invoke same code actually, so a daemonizable scripts should be written first, then we provide several ways of daemonizing them.

So the idea is to add one in place, with a feature to run it if wanted? Or would you have a check balance system to run it. Also, alot of people have a hard time just setting up a blank dB in MySQL, so how would you advise running a basic cron? (no offense to anyone).

You could just create psuedo crons to just execute various things. Maybe to failsafe people using Windows based machines instead of *nix.

http://www.bitfolge.de/pseudocron-en.html]]>
вт, 18 авг 2009 17:44:39 -0000
Trustmaster вт, 18 авг 2009 17:33:57 -0000 Mynt
The best way to make a cron task though is to do it GDLIB style. I find this is the most effecient way. Attaching a simple internal counter to a blank gd_image for views. When the file gets poached and it generates a new one after xxx views, then run the cron. I have set many of those up and see that as being the most effecient since it waits til xxx db queries before it even thinks of running a cron. Pointless to run a crontab on a site that gets less than 600 hits a day with less than 300 posts a day, you know?]]>
вт, 18 авг 2009 15:46:21 -0000
Kilandor
The "race condition" is just referring to, multiple things possibly executing at the same time, which conflict each other and causes problems.

But maybe a better improvement to this feature would be some sort of timer feature for plugin hooks. There could be an extra field in hooks for a timer, so they only are included every so often, then when the script is loaded it can use a function like sed_hook_timer('plug', 'hook', 'newtime'); Then it won't be executed again untill that time.

This would be the best way to do it, No fancy extra complete system for it. All it requires is a new column, and a slight change to hooks. And we can add an new function for easy setting. And we could even go so far as for the admin panel to create on plugin list, to reset timers for all plugins, and for each plugin specifically in the plugin page.

Actually after my idea here, i like it alot. If there are no objections, i'll implement it into the core. As it will also cut back for some people on includes that they don't need.

Cache system definatly should not be used for this, thats not its purpose in anyway]]>
вт, 10 фев 2009 14:41:51 -0000
diablo we can use a second check for unique cron job name
for instance we will run the job "Inactive User Cleaner" its unique name lets say "iuc"
it will check the cache first if its expired it will attempt to add it to its "to-do list" since the job names gonna be unique it will give error when it attempts to add "iuc" to the list. so the at the 1st proc it will be added to list but at 2nd proc it will stop since it will fail adding it to the "list"

so

check cache()
if expired
{
check list()
if not in list
{
add to list*
}
else
{
die
}

}
execute cron job list


* since it wont be able to add list the function wont work further]]>
вт, 10 фев 2009 05:32:49 -0000
Trustmaster race condition on busy sites.]]> вт, 10 фев 2009 05:19:34 -0000 diablo вт, 10 фев 2009 05:08:39 -0000 Trustmaster пт, 22 авг 2008 06:07:36 -0000 Lombi чт, 21 авг 2008 21:00:56 -0000 Lombi чт, 21 авг 2008 20:57:16 -0000 Trustmaster 1. Performance loss due to overhead of calling task manager each request (at least a simple check, but still each request).
2. Interoperability and race conditions. This should be programmed in a "thead-safe" fashion.]]>
чт, 21 авг 2008 04:30:19 -0000
Lombi
basically this system would take care of all "cron" things, but would of course only be aplicable if there's more than 0 people on the site (if noone comes, then nothing gets triggered, like the two forum engines). When the first person comes, the stuff that's been waiting gets run.

Your thoughts?]]>
чт, 21 авг 2008 01:41:40 -0000