Understanding unstructured and indifferent duties in Swift – Donny Wals

While 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 / youngster 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 put up, I’ll give attention to unstructured and indifferent duties. When you’re interested by studying extra about youngster duties, I extremely advocate that you simply learn the next posts:

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

This put up assumes that you simply perceive the fundamentals of structured concurrency which you’ll be able to study extra about in this put up. You don’t must have mastered the subject of structured concurrency, however having some sense of what structured concurrency is all about will provide help to perceive this put up significantly better.

Creating unstructured duties with Job.init

The most typical approach during which you’ll be creating duties in Swift will likely be with Job.init which you’ll most likely write as follows with out spelling out the .init:

Job {
  // carry out work
}

An unstructured job is a job that has no father or mother / youngster 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.

Nevertheless, that doesn’t imply an unstructured job is created completely impartial from every little thing else.

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

• The actor we’re presently working on (if any)
• Job 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 will safely entry an actor’s strategies and properties from inside a job that’s created inside an actor:

actor SampleActor {
  var someCounter = 0

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

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

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

Observe that our job doesn’t have to finish earlier than the incrementCounter() technique returns. That reveals us that the unstructured job that we created isn’t collaborating in structured concurrency. If it have been, incrementCounter() wouldn’t have the ability to full earlier than our job accomplished.

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

@MainActor
func fetchData() {
  Job {
    // this job runs its physique on the principle actor
    let knowledge = await fetcher.getData()

    // self.fashions is up to date on the principle actor
    self.fashions = knowledge
  }
}

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

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

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

When to make use of unstructured duties

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

One more reason to create an unstructured job is perhaps if you wish to carry out a bit of labor independently of the operate you’re in. This may very well be helpful if you’re implementing a fire-and-forget type logging operate for instance. The log would possibly should be despatched off to a server, however as a caller of the log operate I’m not interested by ready for that operation to finish.

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

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

Creating indifferent duties with Job.indifferent

Indifferent duties are in some ways just like unstructured duties. They don’t create a father or mother / youngster relationship, they don’t take part in structured concurrency they usually create a model new island of concurrency that we will work with.

The important thing distinction is {that a} indifferent job won’t inherit something from the context that it was created in. Which means that a indifferent job won’t inherit the present actor, and it’ll not inherit job native values.

Think about the instance you noticed earlier:

actor SampleActor {
  var someCounter = 0

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

As a result of we used a unstructed job on this instance, we have been in a position to work together with our actor’s mutable state with out awaiting it.

Now let’s see what occurs after we make a indifferent job as a substitute:

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Job.indifferent {
      // Actor-isolated property 'someCounter' cannot 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 job. Which means that we now have to work together with the actor by calling its strategies and properties with an await.

Equally, if we create a indifferent job from an @MainActor annotated technique, the indifferent job won’t run its physique on the principle actor:

@MainActor
func fetchData() {
  Job.indifferent {
    // this job runs its physique on a background thread
    let knowledge = await fetcher.getData()

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

Observe that detaching our job has no affect in any respect on the place getData() executed. Since getData() is an async operate it’ll at all times 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 operate runs. It’s the operate itself.

When to make use of indifferent duties

Utilizing a indifferent job solely is sensible if you’re performing work inside the duty physique that you simply wish to run away from any actors it doesn’t matter what. When you’re awaiting one thing inside the indifferent job to ensure the awaited factor runs within the background, a indifferent job is just not the device you ought to be utilizing.

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

So a indifferent job actually solely is sensible if the work you’re doing ought to be away from the principle thread, doesn’t contain awaiting a bunch of features, and the work you’re doing shouldn’t take part in structured concurrency.

As a rule of thumb I keep away from indifferent duties till I discover that I actually need one. Which is just very sporadically.

In Abstract

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

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

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