Support for Many to One Dependencies about overdrive HOT 7 CLOSED

Hi @biocross! Yes, there is a plan to support this once I remove dependency to Foundation.Operation and Foundation.OperationQueue. However, this is a tricky one to implement.

Operation documentation states that:

An operation object is a single-shot object—that is, it executes its task once and cannot be used to execute it again.

That is why you see crashes when you add an existing / finished/ running task as dependency to some other task. To workaround this behaviour, you can use TaskCondition protocol. For example, let's say that you have a tasks named FooTask and BarTask. If you want to express that BarTask always needs a dependency to BarTask, you can do this:

// Create a new condition with explicit dependency to BarTask
class BarTaskCondition: TaskCondition {
  func dependencies<T>(forTask task: Task<T>) -> [Operation] {
      return [BarTask()]
  }
}

Then add it to the FooTask instance.

let task = FooTask()
let condition = BarTaskCondition()

task.add(condition: condition)

TaskQueue.main.add(task: task)

Notice that you don't add BarTask dependency explicitly. Since you expressed it through the TaskCondition, it will be automatically added to the queue. Also, you can add this condition to any task and still have a fresh dependency to BarTask.

To address your other point:

What could be the other behaviour is that when Z came in the first time, Z would have been added to the queue, but the second time, Z would have simply been added as a dependency for B.

This would be hard to implement because you would need to track the task Z state and constantly check if there is a new task with dependency to Z.

A lot of these issues will be fixed by at least enabling re-usage of task instances, which is coming in the near future.

from overdrive.

Appreciate the reply @Arikis

Incidentally, I am adding dependencies exactly by using the dependencies<T>(forTask task: Task<T>) method from a TaskCondition delegate.

My TaskCondition Delegate is a singleton, which returns the dependee task in the array, and Overdrive, as expected, adds the dependee task to the queue.

If more tasks come in depending on same dependee task, the singleton will return the same instance of the dependee task (intentionally, because I don't want this task executed everytime someone depends on it), leading to a crash.

The idea is, is there a way to make multiple tasks wait for the same dependee while the dependee executes.

One way I can think of is, let the external TaskCondition delegate track the state of the dependee task it returns, and instead of returning just [Operation] in the delegate method, return a tuple, with two arguments:

func dependencies<T>(forTask task: Task<T>) -> (operations: [Operation], type: DependencyType)

//Where type is:
public enum DependencyType {
    case add /* Will add the dependencies to queue (current behaviour) */
    case link /* Will simply link current task with .addDependency method to the given dependee operations */
}

from overdrive.

I think that you would be better off without singletons for task conditions. If you need it to be available everywhere, you could return it through a static method.

static func mySharedCondition() -> TaskCondition {
  return MyTaskCondition()
}

Changes you propose could be done by implementing a shared TaskObserver which can be used to track task's state of execution. However, this would also introduce additional checks and locks to synchronise dependency states (dependency might finish in time it's added to some task, even though it was running when checked).

from overdrive.

You're right, but in my case it's the dependency task itself that is the singleton.

Anyway, another thing I'm curious about is that since we can return Operation (and not only Task) as dependencies from the task condition delegate, is there an intentional reason the add(dependency:) method on tasks itself only accepts Task, and not Operations?

I see a method in the Task.swift file which accepts Operation, but it's internal, and is being used at the time of TaskCondition dependency evaluations.

from overdrive.

Problem is that Task is a generic class, thus you can't create an array of arbitrary tasks (which is what we need in that method).

Even if you would use [Task<Any>] as a return type, you would still have to cast from Task<T> to Task<Any>, which is not the best solution. That's why this method currently returns [Operation].

This could be improved by implementing a type-erased class AnyClass (like AnyHashable from Swift Standard Library).

from overdrive.

Closing this one.

from overdrive.

Sure, thanks for your help :)

from overdrive.