I would just use the current cron folder if not objections
On Apr 14, 3:16 am, AchipA wrote:
> Yeah, fairly easy. One question though about the placement of the
> scripts. Most *nixes do this by placing the split files in a separate
> cron.d directory... Should we commandeer the cron directory fo
Yeah, fairly easy. One question though about the placement of the
scripts. Most *nixes do this by placing the split files in a separate
cron.d directory... Should we commandeer the cron directory for this,
or rename it to cron.d (while keeping backward compatibility), put a
cron.d inside cron or...
This an easier one. @Achipa, want to do this?
On Apr 13, 10:49 am, Thadeus Burgess wrote:
> If we are working on cron can I inject a feature request?
>
> Support for multiple crontab files in applications//cron
>
> crontab, or plugin_hi.crontab can be read. Alpha order ?
>
> --
> Thadeus
>
> On T
If we are working on cron can I inject a feature request?
Support for multiple crontab files in applications//cron
crontab, or plugin_hi.crontab can be read. Alpha order ?
--
Thadeus
On Tue, Apr 13, 2010 at 10:47 AM, AchipA wrote:
> Technically, we don't need to nor are we required to skip
Technically, we don't need to nor are we required to skip *exactly*
one minute. The real question is not 'has 60 seconds passed', but
'have we checked cron in this minute'. I would thus check not for a 60
sec offset, but rather if the minute of cron start matches.
Also in line 51:
s.enter(60 - no
I do not like very much the idea of setting ctime/mtime but I do not
like the current mechanism either. It is not just the pickle overhead.
There seem to be precision issues that make it difficult to skip
exactly one minute. For example right now newcron contains:
if startup or self.now - start >
Hey, I don't have a problem with that, just saying the lock-and-read
mechanism can increase the overhead/latency significantly in certain
setups. If a two-file approach is a problem, would you consider
avoiding the cPickle read if I can find a way to do it via setting
ctime/mtime (we set a mtime ol
On Apr 12, 1:19 pm, AchipA wrote:
> Why do we need the time range ? If the tasks are overlapping it's
> their responsibility to handle that (I know this is arguable, but
> that's how 'standard' cron works).
This is also as it works in newcron. The problem is that if for any
reason, the main proce
Why do we need the time range ? If the tasks are overlapping it's
their responsibility to handle that (I know this is arguable, but
that's how 'standard' cron works). Also, we can easily store two
timestamps (slightly hackish, but mtime and ctime can be set
separately), would have to check whether
Because they os timestamp only can only tell you when a task has
started (or stopped, depending on when it was created) it does not
contain enough information to give you a time range (time and stop).
Cron needs to know when the previous crondance started and whether is
was completed or not. The or
To correct myself, it seems the cron in web2py no longer uses the
filesystem timestamps, but cPickles timestamps from/to the lock file.
I'm not sure why Massimo changed it, but this *is* a bigger overhead
than it was previously (as it needs to do file locking and
cPickle.load() on every single requ
I agree. This should be an option but we do not have it yet.
Massimo
On Apr 2, 7:43 pm, Jonathan Lundell wrote:
> On Apr 2, 2010, at 5:18 PM, mdipierro wrote:
>
> > the process that checks for the crontab runs but it does not spawns
> > additional processes if nothing to do.
>
> Understood. But
On Apr 2, 2010, at 5:18 PM, mdipierro wrote:
> the process that checks for the crontab runs but it does not spawns
> additional processes if nothing to do.
Understood. But when it has something to do, if it's lightweight (like expiring
sessions), why run another process ever?
I'm only talking a
the process that checks for the crontab runs but it does not spawns
additional processes if nothing to do.
On Apr 2, 4:14 pm, Jonathan Lundell wrote:
> On Apr 2, 2010, at 12:25 PM, AchipA wrote:
>
> > There was talk about this a few months back, and I even have a dev
> > branch that does exactly
On Apr 2, 2010, at 12:25 PM, AchipA wrote:
> There was talk about this a few months back, and I even have a dev
> branch that does exactly this. There *are* some concerns, that's why I
> have not yet submitted that to Massimo until I resolve GIL/locking/etc
> issues.
It also occurs to me that I c
There was talk about this a few months back, and I even have a dev
branch that does exactly this. There *are* some concerns, that's why I
have not yet submitted that to Massimo until I resolve GIL/locking/etc
issues.
On Apr 2, 12:07 am, Jonathan Lundell wrote:
> On Apr 1, 2010, at 11:20 AM, Achip
On Apr 1, 2010, at 11:20 AM, AchipA wrote:
> Exactly, hardcron checks once a minute, softcron checks on each page
> load. The 'check' is calling a function or two and comparing a file's
> timestamp, so not *that* much more expensive.
Thanks.
In that case, I have a suggestion, perhaps not entirel
Exactly, hardcron checks once a minute, softcron checks on each page
load. The 'check' is calling a function or two and comparing a file's
timestamp, so not *that* much more expensive.
On Apr 1, 7:51 pm, Jonathan Lundell wrote:
> On Apr 1, 2010, at 10:37 AM, AchipA wrote:
>
> > There is some over
On Apr 1, 2010, at 10:37 AM, AchipA wrote:
> There is some overhead, but efficiency is a disputable term - there is
> certainly more overhead than hardcron, but IMO not in a way that would
> affect overall performance unless you're running it on a site that has
> hundreds of thousands of hits per
There is some overhead, but efficiency is a disputable term - there is
certainly more overhead than hardcron, but IMO not in a way that would
affect overall performance unless you're running it on a site that has
hundreds of thousands of hits per day...
On Apr 1, 5:40 pm, Jonathan Lundell wrote:
20 matches
Mail list logo
