-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asyncio task dependency manager #9
Comments
What would be a way to implement "clearing" (and re-triggering?) tasks that came before you? I suppose the we can pass debug log what we were invoked by add |
We added a task manager class and individual tasks' Next up is to implement a could be useful for the task manager to build out a dependency graph (or do like a dry run?) might be worth giving |
dependencies should be a set (de-duplication), finalized should always get cleared when a task or any dependencies are added |
eventual support for pattern matching tasks? |
Next up:
Agree, now that we have support for
Yes, since this should be one of the more practical After that we can look at:
We want something like |
Because it can add a lot of complexity, we may want to start with the pattern matching |
Now that we have dynamic targets implemented, the last thing we need to test is that dynamic targets re-trigger each other. When a |
We should just test some more realistic scenarios and make sure we know what the desired behavior we want is. |
A task should be told at init time whether or not it's dynamic (e.g. provided by If we're a dynamic task being executed and our private inbox doesn't have The problem here is that we want be able to get a correct |
Also, if we want to follow that private inbox chain then we need to set our own private inbox parameters to our parent's inbox data as well |
In the set for literals we need to serialize |
We finally have an implementation for dynamic-target-based task dispatching (including dispatching dependencies correctly). We need some more rigorous tests to ensure that the desired behavior is achieved (dynamic tasks triggering dynamic dependencies and literal dependencies successfully, dependencies invoked on their own later correctly resolved, etc.) Once we're confident the basic task execution and dependency management works, we should implement a |
Implementation is done at this point, we need to clean up the documentation. After this I think we should make some kind of interactive shell with this, could be interesting (e.g. like some program registers all of its dependencies, then you can execute them interactively |
Closing this as I'm about to merge it, time to use it for |
First we need to move the code from a branch on
vmklib
here.We need to make sure we await on all of the dependencies at once and not just serially.
We could test this with a "sleeper" task and make sure one task with 3 one-second sleeps completes in less than 3 seconds.
We need to implement a task that calls
subprocess.run
and make sure that it correctly yieldsThe text was updated successfully, but these errors were encountered: