vine: mainloop improvements

[colinthomas-z80]

WIP

[dthain]

This makes sense so far, but I will wait to merge until making the next release...

[dthain]

Looks good overall, one thing to make tunable.

[dthain]

Status on this one?

[colinthomas-z80]

@dthain I will add the tune option and then it should be good to go

[colinthomas-z80]

do not merge yet, investigating issue

[colinthomas-z80]

bug fixed in #3412

[dthain]

Almost there, last few things.

[dthain]

@colinthomas-z80 don't forget this one...

[dthain]

On the right track, but we need extra care in ensuring each task is in one list at a time.

[dthain]

Please stop by to talk, I think it's easier to explain in person...

[colinthomas-z80]

@dthain I moved the mechanism of removing/adding to any task state list to change_task_state.

There are a few separate scenarios where we might change tasks to VINE_TASK_RETRIEVED so that motivates keeping list operations in a single place.

[dthain]

Ah, I think you took my advice in the opposite direction.

Your code assumes that a task always marches through the states linearly from READY to DONE.
But that's not the case b/c it can also do these things:

• RUNNING -> CANCELLED
• READY -> RUNNING
• READY -> DONE

So, I don't think it is quite right for change_task_state to do the pops as well as the pushes.

I think what you want here is for each action in the code to remove a task from a data structure, consider what to do with it, and then either put it back or call change_task_state.

Under that model, change_task_statewould only push things onto the data structures.

[dthain]

Almost there