scheduler 'tasks' vs 'runs'

[Tom Clerckx]

The current scheduler in py4web only has the concept of task_runs

In web2py there was a separation between a task and its runs

The separation of tasks and runs in web2py made it easy to manage tasks, specially periodic tasks.

In py4web, if I schedule a periodic task:

1) A new run of the task will only be executed when the previous run has completed

2) How to change the period of a scheduled task? Stop the current running instance and start a new schedule?

3) If the scheduler is stopped for whatever reason, the periodic task becomes 'dead' and no new instances are scheduled.

Are there any plans to evolve the scheduler in py4web (more towards the one that exists in web2py)?

[Massimo DiPierro]

This was an intentional design decision to keep things simpler. I think the problems that you mention can be addressed within the current design.

For example:

def task_submitter():

     scheduler.enqueue_run("executor", scheduled_for=now())

def task_executor():

     time.sleep(100)

scheduler.register_task("submitter", task_submitter)

scheduler.register_task("executor", task_executor)

scheduler.enqueue_run("submitter", period=10)

The job of the submitter is that of creating executor tasks. In the example they start every 10s and take 100s. This should address 1,2,3.

Specifically executor runs will start even if the previous ones have not completed. You can change the period with

db.task_run(name="submitter").update_record(period=20)

I believe this is in fact more flexible that the web2py scheduler design because you can add your own logic to the task_executor. It could for example schedule even more than a single task.

Please let me know if this does not work or if I am missing anything.

Massimo

[Dave S]

On Monday, September 1, 2025 at 8:55:13 AM UTC-7 Massimo DiPierro wrote:

This was an intentional design decision to keep things simpler. I think the problems that you mention can be addressed within the current design.

For example:

def task_submitter():

     scheduler.enqueue_run("executor", scheduled_for=now())

def task_executor():

     time.sleep(100)

scheduler.register_task("submitter", task_submitter)

scheduler.register_task("executor", task_executor)

scheduler.enqueue_run("submitter", period=10)

The job of the submitter is that of creating executor tasks. In the example they start every 10s and take 100s. This should address 1,2,3.

Specifically executor runs will start even if the previous ones have not completed. You can change the period with

db.task_run(name="submitter").update_record(period=20)

I believe this is in fact more flexible that the web2py scheduler design because you can add your own logic to the task_executor.

Did you mean "task_scheduler" here?  "task_executor" is not implausible, but given the context I think the scheduler fits your suggestion better and is the cleaner design.

/dps  

[Massimo DiPierro]

I messed up the names. I will rename them:

def task_scheduler():

     scheduler.enqueue_run("task_executor", scheduled_for=now())

def task_executor():

     time.sleep(100)

scheduler.register_task("task_scheduler", task_scheduler)

scheduler.register_task("task_executor", task_executor)

scheduler.enqueue_run("task_scheduler", period=10)

[Tom Clerckx]

I think that will do it for now.

Still need to look further into the whole scheduler part.

Thanks