From: Jonathan Ellis <jonathan@si...> - 2005-03-17 21:10:43
[Replying on-list since others might be interested.]
On Thu, 17 Mar 2005 13:21:53 -0500 (EST), "Rimon Barr"
> Interesting... I was thinking of something like this.
> My question for you is... Do you really expect the scheduled task to run
> WHILE a request is being processed?
Yes; tasks won't have any more synch issues than concurrent requests
already do, so I expect people to solve both with the same tool, whether
that's rlock or something else.
> What if it's a really long task?
It's easy to give as your "long task" a callable like "lambda:
threading.Thread(target=longcallable).start()". I'll mention this in
the docs, but I don't think it's the scheduler's job to specialcase
> What are the kinds of things that you want to do with this module, and
> what execution semantics do you want to support: at least once, at most
> once, exactly once.
It's inspired by the AOLserver scheduled task functionality; I've used
that extensively and the combination of "run this every N seconds" and
"run this every day at HH:MM" covers pretty much everything. Both
schedule functions take an optional "once" boolean; they also return the
Task object so if you want to do something strange like run exactly 3
times, you can set task.last = True from the callable itself.
Some things I have done with scheduled tasks:
- Scan the log for errors and email me a summary
- vacuum (pre-autovacuum daemon days...)
- Purge stuff from the global cache
- Send email to users whose accounts are about to be suspended
Basically anything you might use cron for, except that it integrates
better with your service; you can access your db pool and other global
state without having to do ugly things from an external script.
> And what kinds of guarantees do you provide if not a
> single request comes in during that time?
For now it runs in a separate thread, so it's really only an option if
you're running spyceWWW... If someone else wants to extend it to work
with CGI/mod_python, then great. I don't think you're going to be able
to do better than "check before each request" in a CGI environment, though.