If you simply begin out with studying Swift Concurrency you’ll discover that there are a number of methods to create new duties. One method creates a father or mother / baby relationship between duties, one other creates duties which might be unstructured however do inherit some context and there’s an method that creates duties which might be utterly indifferent from all context.

On this submit, I’ll deal with unstructured and indifferent duties. In case you’re taken with studying extra about baby duties, I extremely suggest that you simply learn the next posts:

These two posts go in depth on the connection between father or mother and baby duties in Swift Concurrency, how cancellation propagates between duties, and extra.

This submit assumes that you simply perceive the fundamentals of structured concurrency which you’ll be able to be taught extra about in this submit. You don’t should have mastered the subject of structured concurrency, however having some sense of what structured concurrency is all about will enable you perceive this submit significantly better.

Creating unstructured duties with Activity.init

The commonest means during which you’ll be creating duties in Swift will probably be with Activity.init which you’ll most likely write as follows with out spelling out the .init:

Activity {
  // carry out work
}

An unstructured process is a process that has no father or mother / baby relationship with the place it referred to as from, so it doesn’t take part in structured concurrency. As an alternative, we create a very new island of concurrency with its personal scopes and lifecycle.

Nonetheless, that doesn’t imply an unstructured process is created fully unbiased from every thing else.

An unstructured process will inherit two items of context from the place it’s created:

• The actor we’re at present working on (if any)
• Activity native values

The primary level implies that any duties that we create inside an actor will take part in actor isolation for that particular actor. For instance, we are able to safely entry an actor’s strategies and properties from inside a process that’s created inside an actor:

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Activity {
      someCounter += 1
    }
  }
}

If we had been to mutate someCounter from a context that’s not working on this particular actor we’d should prefix our someCounter += 1 line with an await since we’d have to attend for the actor to be out there.

This isn’t the case for an unstructured process that we’ve created from inside an actor.

Observe that our process doesn’t have to finish earlier than the incrementCounter() technique returns. That reveals us that the unstructured process that we created isn’t taking part in structured concurrency. If it had been, incrementCounter() wouldn’t be capable of full earlier than our process accomplished.

Equally, if we spawn a brand new unstructured process from a context that’s annotated with @MainActor, the duty will run its physique on the primary actor:

@MainActor
func fetchData() {
  Activity {
    // this process runs its physique on the primary actor
    let information = await fetcher.getData()

    // self.fashions is up to date on the primary actor
    self.fashions = information
  }
}

It’s necessary to notice that the await fetcher.getData() line does not block the primary actor. We’re calling getData() from a context that’s working on the primary actor however that doesn’t imply that getData() itself will run its physique on the primary actor. Until getData() is explicitly related to the primary actor it’ll all the time run on a background thread.

Nonetheless, the duty does run its physique on the primary actor so as soon as we’re now not ready for the results of getData(), our process resumes and self.fashions is up to date on the primary actor.

Observe that whereas we await one thing, our process is suspended which permits the primary actor to do different work whereas we wait. We don’t block the primary actor by having an await on it. It’s actually fairly the other.

When to make use of unstructured duties

You’ll mostly create unstructured duties while you wish to name an async annotated perform from a spot in your code that’s not but async. For instance, you may wish to fetch some information in a viewDidLoad technique, otherwise you may wish to begin iterating over a few async sequences from inside a single place.

Another excuse to create an unstructured process is perhaps if you wish to carry out a bit of labor independently of the perform you’re in. This might be helpful while you’re implementing a fire-and-forget model logging perform for instance. The log may have to be despatched off to a server, however as a caller of the log perform I’m not taken with ready for that operation to finish.

func log(_ string: String) {
  print("LOG", string)
  Activity {
    await uploadMessage(string)
    print("message uploaded")
  }
}

We might have made the strategy above async however then we wouldn’t be capable of return from that technique till the log message was uploaded. By placing the add in its personal unstructured process we enable log(_:) to return whereas the add continues to be ongoing.

Creating indifferent duties with Activity.indifferent

Indifferent duties are in some ways much like unstructured duties. They don’t create a father or mother / baby relationship, they don’t take part in structured concurrency and so they create a model new island of concurrency that we are able to work with.

The important thing distinction is {that a} indifferent process is not going to inherit something from the context that it was created in. Because of this a indifferent process is not going to inherit the present actor, and it’ll not inherit process native values.

Contemplate the instance you noticed earlier:

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Activity {
      someCounter += 1
    }
  }
}

As a result of we used a unstructed process on this instance, we had been capable of work together with our actor’s mutable state with out awaiting it.

Now let’s see what occurs once we make a indifferent process as an alternative:

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Activity.indifferent {
      // Actor-isolated property 'someCounter' can't be mutated from a Sendable closure
      // Reference to property 'someCounter' in closure requires specific use of 'self' to make seize semantics specific
      someCounter += 1
    }
  }
}

The compiler now sees that we’re now not on the SampleActor inside our indifferent process. Because of this we’ve to work together with the actor by calling its strategies and properties with an await.

Equally, if we create a indifferent process from an @MainActor annotated technique, the indifferent process is not going to run its physique on the primary actor:

@MainActor
func fetchData() {
  Activity.indifferent {
    // this process runs its physique on a background thread
    let information = await fetcher.getData()

    // self.fashions is up to date on a background thread
    self.fashions = information
  }
}

Observe that detaching our process has no influence in any respect on the place getData() executed. Since getData() is an async perform it’ll all the time run on a background thread except the strategy was explicitly annotated with an @MainActor annotation. That is true no matter which actor or thread we name getData() from. It’s not the callsite that decides the place a perform runs. It’s the perform itself.

When to make use of indifferent duties

Utilizing a indifferent process solely is smart while you’re performing work inside the duty physique that you simply wish to run away from any actors it doesn’t matter what. In case you’re awaiting one thing inside the indifferent process to ensure the awaited factor runs within the background, a indifferent process will not be the instrument you need to be utilizing.

Even in case you solely have a gradual for loop inside a indifferent process, or your encoding a considerable amount of JSON, it’d make extra sense to place that work in an async perform so you will get the advantages of structured concurrency (the work should full earlier than we are able to return from the calling perform) in addition to the advantages of working within the background (async features run within the background by default).

So a indifferent process actually solely is smart if the work you’re doing must be away from the primary thread, doesn’t contain awaiting a bunch of features, and the work you’re doing mustn’t take part in structured concurrency.

As a rule of thumb I keep away from indifferent duties till I discover that I really want one. Which is barely very sporadically.

In Abstract

On this submit you realized concerning the variations between indifferent duties and unstructured duties. You realized that unstructured duties inherit context whereas indifferent duties don’t. You additionally realized that neither a indifferent process nor an unstructured process turns into a baby process of their context as a result of they don’t take part in structured concurrency.

You realized that unstructured duties are the popular strategy to create new duties. You noticed how unstructured duties inherit the actor they’re created from, and also you realized that awaiting one thing from inside a process doesn’t be sure that the awaited factor runs on the identical actor as your process.

After that, you realized how indifferent duties are unstructured, however they don’t inherit any context from when they’re created. In follow which means that they all the time run their our bodies within the background. Nonetheless, this doesn’t be sure that awaited features additionally run within the background. An @MainActor annotated perform will all the time run on the primary actor, and any async technique that’s not constrained to the primary actor will run within the background. This habits makes indifferent duties a instrument that ought to solely be used when no different instrument solves the issue you’re fixing.