The way to decide the place duties and async capabilities run in Swift?

Swift’s present concurrency mannequin leverages duties to encapsulate the asynchronous work that you simply’d wish to carry out. I wrote concerning the totally different sorts of duties we have now in Swift previously. You possibly can check out that put up right here. On this put up, I’d wish to discover the foundations that Swift applies when it determines the place your duties and capabilities run. Extra particularly, I’d wish to discover how we will decide whether or not a process or operate will run on the primary actor or not.

We’ll begin this put up by very briefly taking a look at duties and the way we will decide the place they run. I’ll dig proper into the small print so when you’re not solely updated on the fundamentals of Swift’s unstructured and indifferent duties, I extremely advocate that you simply catch up right here.

After that, we’ll have a look at asynchronous capabilities and the way we will cause about the place these capabilities run.

To comply with together with this put up, it’s advisable that you simply’re considerably updated on Swift’s actors and the way they work. Check out my put up on actors if you wish to be sure you’ve obtained crucial ideas down.

Reasoning about the place a Swift Activity will run

In Swift, we have now two sorts of duties:

• Unstructured duties
• Indifferent duties

Every process kind has its personal guidelines concerning the place the duty will run its physique.

While you create a indifferent process, this process will at all times run its physique utilizing the worldwide executor. In sensible phrases which means that a indifferent process will at all times run on a background thread. You possibly can create a indifferent process as follows:

Activity.indifferent {
  // this runs on the worldwide executor
}

A indifferent process ought to hardly be utilized in apply as a result of there are different methods to carry out work within the background that don’t contain beginning a brand new process (that doesn’t take part in structured concurrency).

The opposite option to begin a brand new process is by creating an unstructured process. This appears to be like as follows:

Activity {
  // this runs ... someplace?
}

An unstructured process will inherit sure issues from its context, like the present actor for instance. It’s this present actor that determines the place our unstructured process will run.

Typically it’s fairly apparent that we wish a process to run on the primary actor:

Activity { @MainActor in 

}

Whereas this process inherits an actor from the present context, we’re overriding this by annotating our process physique with MainActor to be sure that our process’s physique runs on the primary actor.

Fascinating sidenote: you are able to do the identical with a indifferent process.

Moreover, we will create a brand new process that’s on the primary actor like this:

@MainActor
struct MyView: View {
  // physique and many others...

  func startTask() {
    Activity {
      // this process runs on the primary actor
    }
  }
}

Our SwiftUI view on this instance is annotated with @MainActor. Because of this each operate and property that’s outlined on MyView will probably be executed on the primary actor. Together with our startTask operate. The Activity inherits the primary actor from MyView so it’s working its physique on the primary actor.

If we make one small change to the view, the whole lot modifications:

struct MyView: View {
  // physique and many others...

  func startTask() {
    Activity {
      // this process mightrun on the primary actor
    }
  }
}

As a substitute of understanding that startTask will run on the primary actor, we’re no longer so certain about the place this process will run. The rationale for that is that it now is dependent upon the place we name startTask from. If we name startTask from a process that we’ve outlined on view’s physique utilizing the process view modifier, we’re working in a important actor context as a result of the duty that’s created by the view modifier is related to the primary actor.

If we name startTask from a non-main actor remoted spot, like a indifferent process or an asynchronous operate then our process physique will run on the worldwide executor. Even calling startTask from a button motion will trigger the Activity to run on the worldwide executor.

At runtime, the one option to take a look at this that I do know off is to make use of the deprecated Thread.isMainThread property or to place a breakpoint in your process’s physique after which see which thread your program pauses on.

As a rule of thumb you can say {that a} Activity will at all times run within the background when you’re not connected to any actors. That is the case once you create a brand new Activity from any object that’s not important actor annotated for instance. While you create your process from a spot that’s important actor annotated, you recognize your process will run on the primary actor.

Sadly, this isn’t at all times simple to find out and Apple appears to need us to not fear an excessive amount of about this.

Fortunately, the way in which async capabilities work in Swift can provide us some confidence in ensuring that we don’t block the primary actor by chance.

Reasoning about the place an async operate runs in Swift

Everytime you wish to name an async operate in Swift, it’s important to do that from a process and it’s important to do that from inside an current asynchronous context. For those who’re not but in an async operate you’ll normally create this asynchronous context by making a brand new Activity object.

From inside that process you’ll name your async operate and prefix the decision with the await key phrase. It’s a standard false impression that once you await a operate name the duty you’re utilizing the await from will probably be blocked till the operate you’re ready for is accomplished. If this have been true, you’d at all times wish to be certain that your duties run away from the primary actor to be sure you’re not blocking the primary actor when you’re ready for one thing like a community name to finish.

Fortunately, awaiting one thing does not block the present actor. As a substitute, it units apart all work that’s ongoing in order that the actor you have been on is free to carry out different work. I gave a chat the place I went into element on this. You possibly can see the speak right here.

Realizing all of this, let’s discuss how we will decide the place an async operate will run. Look at the next code:

struct MyView: View {
  // physique and many others...

  func performWork() async {
    // Can we decide the place this operate runs?
  }
}

The performWork operate is marked async which implies that we should name it from inside an async context, and we have now to await it.

An affordable assumption can be to count on this operate to run on the actor that we’ve known as this operate from.

For instance, within the following scenario you would possibly count on performWork to run on the primary actor:

struct MyView: View {
  var physique: some View {
    Textual content("Pattern...")
      .process {
        await peformWork()
      }
  }

  func performWork() async {
    // Can we decide the place this operate runs?
  }
}

Curiously sufficient, peformWork will not run on the primary actor on this case. The rationale for that’s that in Swift, capabilities don’t simply run on no matter actor they have been known as from. As a substitute, they run on the worldwide executor except instructed in any other case.

In sensible phrases, which means that your asynchronous capabilities will have to be both immediately or not directly annotated with the primary actor if you need them to run on the primary actor. In each different scenario your operate will run on the worldwide executor.

Whereas this rule is easy sufficient, it may be tough to find out precisely whether or not or not your operate is implicitly annotated with @MainActor. That is normally the case when there’s inheritance concerned.

A less complicated instance appears to be like as follows:

@MainActor
struct MyView: View {
  var physique: some View {
    Textual content("Pattern...")
      .process {
        await peformWork()
      }
  }

  func performWork() async {
    // This operate will run on the primary actor
  }
}

As a result of we’ve annotated our view with @MainActor, the asynchronous performWork operate inherits the annotation and it’ll run on the primary actor.

Whereas the apply of reasoning about the place an asynchronous operate will run isn’t simple, I normally discover this simpler than reasoning about the place my Activity will run nevertheless it’s nonetheless not trivial.

The bottom line is at all times to have a look at the operate itself first. If there’s no @MainActor, you’ll be able to have a look at the enclosing object’s definition. After that you could have a look at base courses and protocols to ensure there isn’t any important actor affiliation there.

At runtime, you’ll be able to place a breakpoint or print the deprecated Thread.isMainThread property to see in case your async operate runs on the primary actor. If it does, you’ll know that there’s some important actor annotation that’s utilized to your asynchronous operate. For those who’re not working on the primary actor, you’ll be able to safely say that there’s no important actor annotation utilized to your operate.

In Abstract

Swift Concurrency’s guidelines for figuring out the place a process or operate runs are comparatively clear and particular. Nevertheless, in apply issues can get a bit muddy for duties as a result of it’s not at all times trivial to cause about whether or not or that your process is created from a context that’s related to the primary actor. Observe that working on the primary thread is just not the identical as being related to the primary actor.

For async capabilities we will cause extra regionally which ends up in a neater psychological modal nevertheless it’s nonetheless not trivial.

We will use Thread.isMainThread and breakpoints to determine whether or not our code is working on the primary thread however these instruments aren’t excellent and we don’t have any higher alternate options in the intervening time (that I do know off).

You probably have any additions, questions, or feedback on this text please don’t hesitate to achieve out on X.