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 mother or father / baby relationship between duties, one other creates duties which are unstructured however do inherit some context and there’s an method that creates duties which are fully indifferent from all context.

On this put up, I’ll give attention to unstructured and indifferent duties. In the event you’re curious about studying extra about baby duties, I extremely advocate that you just learn the next posts:

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

This put up assumes that you just 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 assist you to perceive this put up a lot better.

Creating unstructured duties with Process.init

The most typical means wherein you’ll be creating duties in Swift can be with Process.init which you’ll in all probability write as follows with out spelling out the .init:

Process {
  // carry out work
}

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

Nevertheless, that doesn’t imply an unstructured process is created solely unbiased from all the things 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)
• Process native values

The primary level implies that any duties that we create within 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 process that’s created within an actor:

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Process {
      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 would have to attend for the actor to be accessible.

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

Notice that our process doesn’t have to finish earlier than the incrementCounter() methodology returns. That exhibits us that the unstructured process that we created isn’t taking part in structured concurrency. If it have 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() {
  Process {
    // this process runs its physique on the primary actor
    let knowledge = await fetcher.getData()

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

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. Except getData() is explicitly related to the primary actor it can at all times run on a background thread.

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

Notice 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 alternative.

When to make use of unstructured duties

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

Another excuse to create an unstructured process could be if you wish to carry out a bit of labor independently of the perform you’re in. This may very well be helpful if you’re implementing a fire-and-forget type logging perform for instance. The log would possibly have to be despatched off to a server, however as a caller of the log perform I’m not curious about ready for that operation to finish.

func log(_ string: String) {
  print("LOG", string)
  Process {
    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 methodology 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 Process.indifferent

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

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

Think about the instance you noticed earlier:

actor SampleActor {
  var someCounter = 0

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

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

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

actor SampleActor {
  var someCounter = 0

  func incrementCounter() {
    Process.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 not on the SampleActor within our indifferent process. Which means 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 methodology, the indifferent process won’t run its physique on the primary actor:

@MainActor
func fetchData() {
  Process.indifferent {
    // this process 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
  }
}

Notice that detaching our process has no impression in any respect on the place getData() executed. Since getData() is an async perform it can at all times run on a background thread until 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 if you’re performing work within the duty physique that you just wish to run away from any actors it doesn’t matter what. In the event you’re awaiting one thing within the indifferent process to verify the awaited factor runs within the background, a indifferent process will not be the instrument you have to be utilizing.

Even if you happen to solely have a sluggish for loop within a indifferent process, otherwise you’re encoding a considerable amount of JSON, it would make extra sense to place that work in an async perform so you may get the advantages of structured concurrency (the work should full earlier than we will 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 ought to 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 actually need one. Which is barely 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 process nor an unstructured process turns into a toddler process of their context as a result of they don’t take part in structured concurrency.

You discovered that unstructured duties are the popular technique 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 process doesn’t make sure that the awaited factor runs on the identical actor as your process.

After that, you discovered how indifferent duties are unstructured, however they don’t inherit any context from when they’re created. In observe which means 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 perform will at all times run on the primary actor, and any async methodology that’s not constrained to the primary actor will run within the background. This conduct makes indifferent duties a instrument that ought to solely be used when no different instrument solves the issue you’re fixing.