Printed on: February 16, 2024
Swift’s present concurrency mannequin leverages duties to encapsulate the asynchronous work that you simply’d prefer to carry out. I wrote in regards to the completely different sorts of duties we’ve got in Swift previously. You’ll be able to check out that submit right here. On this submit, I’d prefer to discover the foundations that Swift applies when it determines the place your duties and features run. Extra particularly, I’d prefer to discover how we will decide whether or not a job or operate will run on the primary actor or not.
We’ll begin this submit 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 in case you’re not completely updated on the fundamentals of Swift’s unstructured and indifferent duties, I extremely suggest that you simply catch up right here.
After that, we’ll have a look at asynchronous features and the way we will cause about the place these features run.
To observe together with this submit, it’s really helpful that you simply’re considerably updated on Swift’s actors and the way they work. Check out my submit on actors if you wish to be sure you’ve obtained a very powerful ideas down.
Reasoning about the place a Swift Process will run
In Swift, we’ve got two sorts of duties:
- Unstructured duties
- Indifferent duties
Every job sort has its personal guidelines relating to the place the duty will run its physique.
Whenever you create a indifferent job, this job will at all times run its physique utilizing the worldwide executor. In sensible phrases which means that a indifferent job will at all times run on a background thread. You’ll be able to create a indifferent job as follows:
Process.indifferent {
// this runs on the worldwide executor
}A indifferent job ought to hardly be utilized in observe as a result of there are different methods to carry out work within the background that don’t contain beginning a brand new job (that doesn’t take part in structured concurrency).
The opposite approach to begin a brand new job is by creating an unstructured job. This seems as follows:
Process {
// this runs ... someplace?
}An unstructured job will inherit sure issues from its context, like the present actor for instance. It’s this present actor that determines the place our unstructured job will run.
Generally it’s fairly apparent that we would like a job to run on the primary actor:
Process { @MainActor in
}Whereas this job inherits an actor from the present context, we’re overriding this by annotating our job physique with MainActor to ensure that our job’s physique runs on the primary actor.
Attention-grabbing sidenote: you are able to do the identical with a indifferent job.
Moreover, we will create a brand new job that’s on the primary actor like this:
@MainActor
struct MyView: View {
// physique and so on...
func startTask() {
Process {
// this job 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 might be executed on the primary actor. Together with our startTask operate. The Process 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, every thing modifications:
struct MyView: View {
// physique and so on...
func startTask() {
Process {
// this job mightrun on the primary actor
}
}
}As a substitute of realizing that startTask will run on the primary actor, we’re no longer so positive about the place this job will run. The explanation for that is that it now is dependent upon the place we name startTask from. If we name startTask from a job that we’ve outlined on view’s physique utilizing the job view modifier, we’re working in a major 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 job or an asynchronous operate then our job physique will run on the worldwide executor. Even calling startTask from a button motion will trigger the Process to run on the worldwide executor.
At runtime, the one approach 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 job’s physique after which see which thread your program pauses on.
As a rule of thumb you possibly can say {that a} Process will at all times run within the background in case you’re not hooked up to any actors. That is the case once you create a brand new Process from any object that’s not major actor annotated for instance. Whenever you create your job from a spot that’s major actor annotated, you already know your job will run on the primary actor.
Sadly, this isn’t at all times easy to find out and Apple appears to need us to not fear an excessive amount of about this.
Fortunately, the best way async features work in Swift may give 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 need to name an async operate in Swift, it’s important to do that from a job and it’s important to do that from inside an present asynchronous context. In case you’re not but in an async operate you’ll often create this asynchronous context by making a brand new Process object.
From inside that job 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 might be blocked till the operate you’re ready for is accomplished. If this have been true, you’d at all times need to be certain that your duties run away from the primary actor to be sure you’re not blocking the primary actor whilst 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’ll be able to see the discuss 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 so on...
func performWork() async {
// Can we decide the place this operate runs?
}
}The performWork operate is marked async which signifies that we should name it from inside an async context, and we’ve got to await it.
An affordable assumption could be to anticipate this operate to run on the actor that we’ve known as this operate from.
For instance, within the following state of affairs you may anticipate performWork to run on the primary actor:
struct MyView: View {
var physique: some View {
Textual content("Pattern...")
.job {
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 explanation for that’s that in Swift, features 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 features 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 state of affairs your operate will run on the worldwide executor.
Whereas this rule is simple sufficient, it may be tough to find out precisely whether or not or not your operate is implicitly annotated with @MainActor. That is often the case when there’s inheritance concerned.
An easier instance seems as follows:
@MainActor
struct MyView: View {
var physique: some View {
Textual content("Pattern...")
.job {
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 observe of reasoning about the place an asynchronous operate will run isn’t easy, I often discover this simpler than reasoning about the place my Process will run but it surely’s nonetheless not trivial.
The secret’s at all times to take 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 which you could have a look at base lessons and protocols to ensure there isn’t any major 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 major actor annotation that’s utilized to your asynchronous operate. In case you’re not working on the primary actor, you’ll be able to safely say that there’s no major actor annotation utilized to your operate.
In Abstract
Swift Concurrency’s guidelines for figuring out the place a job or operate runs are comparatively clear and particular. Nonetheless, in observe issues can get a little bit muddy for duties as a result of it’s not at all times trivial to cause about whether or not or that your job is created from a context that’s related to the primary actor. Observe that working on the primary thread will not be the identical as being related to the primary actor.
For async features we will cause extra regionally which leads to a neater psychological modal but it surely’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 mean time (that I do know off).
When you’ve got any additions, questions, or feedback on this text please don’t hesitate to achieve out on X.
