| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that when a linear flow or derivatives is running
that it can not be modified by another thread at the same
time it is running by putting a lock around sensitive functions.
Also instead of using the raw task objects themselves
integrate a helper 'runner' class that provides useful
functionality that occurs before its tasks runs as well
as member variables that are associated with the contained
task.
This helper class currently provides the following:
- A uuid that can be returned to callers of the add
method to identify there task (and later its results),
allowing for multiple of the same tasks to be added.
- Automatic extraction of the needed required and optional
inputs for the contained task.
Change-Id: Ib01939a4726155a629e4b4703656b9067868d8f3
|
| |
|
|
|
|
|
|
|
|
|
| |
1. In order to aid future features its useful to split
split apart the linear_flow and have a good base
class that is not connected to a ordered or linear flow.
2. Have the graph flow inherit from the linear flow since
it is performing a linear run using a topological ordering
of the tasks.
Change-Id: I287cd4a666caf09ca3a4cdf1d53814e9c6feb765
|
| |
|
|
| |
Change-Id: Ia29e0e8a54fa815dec88016a9444fe7cfad7b8ac
|
| |
|
|
|
|
|
|
| |
The test pip ordering was resulting in the pep8 rules not really
running so this fixes that up and the resulting errors so we can
get a clean run.
Change-Id: Icc27be05cd513c4f04135c7e768007dbf9d07b10
|
| |
|
|
| |
Change-Id: I5ff975bb5ded48a84341efa4ebfdae4bf430ab60
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Instead of requiring a apply() function just use the
built-in one provided by objects or functions implementing
__call__. Also change how requires/provides may not be found
if functors are just passed in (since functors implement
__call__).
|
| |
|
|
|
|
| |
Use a new rollback accumulator to collect which tasks need to be rolled back
and use that in the ordered workflow code. Move the usage of provides/requires
as functions and just let them be attributes of the flow objects.
|
| |
|
|
|
|
|
| |
Incases where a item is produced by 2+ tasks we should allow
the task that depends on that item to get the 2+ items produced
as a list of items. We can also disallow this type of production
via a new boolean option.
|
| | |
|
| | |
|
| |
|
|
|
| |
Ensure that we connect from some input to some node that provides
said input (not itself).
|
| | |
|
| |
|
