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 totally different sorts of duties we’ve in Swift up to now. You’ll be able to check out that submit right here. On this submit, I’d prefer to discover the principles that Swift applies when it determines the place your duties and capabilities run. Extra particularly, I’d prefer 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 submit by very briefly 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 totally 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 take a look at asynchronous capabilities and the way we will cause about the place these capabilities run.
To comply with together with this submit, it’s advisable 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 two sorts of duties:
- Unstructured duties
- Indifferent duties
Every process sort has its personal guidelines relating to the place the duty will run its physique.
Once 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’ll be able to create a indifferent process as follows:
Process.indifferent {
// this runs on the worldwide executor
}A indifferent process ought to rarely 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 process (that doesn’t take part in structured concurrency).
The opposite strategy to begin a brand new process is by creating an unstructured process. This appears to be like as follows:
Process {
// 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 would like a process to run on the primary actor:
Process { @MainActor in
}Whereas this process inherits an actor from the present context, we’re overriding this by annotating our process physique with MainActor to make it possible for our process’s physique runs on the primary actor.
Attention-grabbing 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 so forth...
func startTask() {
Process {
// this process runs on the primary actor
}
}
}Our SwiftUI view on this instance is annotated with @MainActor. Which means that each operate and property that’s outlined on MyView shall be executed on the primary actor. Together with our startTask operate. The Process inherits the primary actor from MyView so it’s operating its physique on the primary actor.
If we make one small change to the view, the whole lot modifications:
struct MyView: View {
// physique and so forth...
func startTask() {
Process {
// this process mightrun on the primary actor
}
}
}As an alternative of figuring out that startTask will run on the primary actor, we’re not so positive about the place this process will run. The explanation for that is that it now will depend on 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 operating 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 Process to run on the worldwide executor.
At runtime, the one strategy to check 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 may 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 important actor annotated for instance. Once you create your process from a spot that’s important actor annotated, you understand your process 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 way in which async capabilities work in Swift may give us some confidence in ensuring that we don’t block the primary actor accidentally.
Reasoning about the place an async operate runs in Swift
Everytime you need to name an async operate in Swift, it’s a must to do that from a process and it’s a must to do that from inside an current asynchronous context. When 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 process you’ll name your async operate and prefix the decision with the await key phrase. It’s a typical false impression that once you await a operate name the duty you’re utilizing the await from shall be blocked till the operate you’re ready for is accomplished. If this had been true, you’d at all times need to be sure 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 an alternative, it units apart all work that’s ongoing in order that the actor you had 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 speak right here.
Understanding all of this, let’s speak about how we will decide the place an async operate will run. Study the next code:
struct MyView: View {
// physique and so forth...
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’ve 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 state of affairs 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?
}
}Apparently sufficient, peformWork will not run on the primary actor on this case. The explanation for that’s that in Swift, capabilities don’t simply run on no matter actor they had been known as from. As an alternative, they run on the worldwide executor except instructed in any other case.
In sensible phrases, which means that your asynchronous capabilities will must be both straight or not directly annotated with the primary actor if you’d like 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 difficult 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.
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 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 however it’s nonetheless not trivial.
The secret is at all times to have a look at the operate itself first. If there’s no @MainActor, you’ll be able to take a look at the enclosing object’s definition. After which you can take a look at base lessons and protocols to verify 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. When you’re not operating 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 observe 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 operating on the primary thread shouldn’t be 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 however it’s nonetheless not trivial.
We are able to use Thread.isMainThread and breakpoints to determine whether or not our code is operating on the primary thread however these instruments aren’t good and we don’t have any higher options in the meanwhile (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.