asyncDetached falling back into main thread after MainActor call

Question

[Warning! In case anyone runs across this question: it was asked very early in the history of the introduction of async/await into Swift. The problem it poses was probably a bug, indeed; but that bug is gone. The behavior described in the question is no longer reproducible. I've added a note at the end of the question, saying what happens now.]

---

I'm trying out the new async/await stuff. My goal here is to run the test() method in the background, so I use Task.detached; but during test() I need to make a call on the main thread, so I'm using MainActor.

(I realize that this may look convoluted in isolation, but it's pared down from a much better real-world case.)

Okay, so test code looks like this (in a view controller):

override func viewDidLoad() {
    super.viewDidLoad()
    Task.detached(priority: .userInitiated) {
        await self.test()
    }
}
@MainActor func getBounds() async -> CGRect {
    let bounds = self.view.bounds
    return bounds
}
func test() async {
    print("test 1", Thread.isMainThread) // false
    let bounds = await self.getBounds()
    print("test 2", Thread.isMainThread) // true
}

The first print says I'm not on the main thread. That's what I expect.

But the second print says I am on the main thread. That isn't what I expect.

It feels as if I've mysteriously fallen back into the main thread just because I called a MainActor function. I thought I would be waiting for the main thread and then resuming in the background thread I was already on.

Is this a bug, or are my expectations mistaken? If the latter, how do I step out to the main thread during await but then come back to the thread I was on? I thought this was exactly what async/await would make easy...?

(I can "solve" the problem, in a way, by calling Task.detached again after the call to getBounds; but at that point my code looks so much like nested GCD that I have to wonder why I'm using async/await at all.)

Maybe I'm being premature but I went ahead and filed this as a bug: https://bugs.swift.org/browse/SR-14756.

---

More notes:

I can solve the problem by replacing

    let bounds = await self.getBounds()

with

    async let bounds = self.getBounds()
    let thebounds = await bounds

But that seems unnecessarily elaborate, and doesn't convince me that the original phenomenon is not a bug.

---

I can also solve the problem by using actors, and this is starting to look like the best approach. But again, that doesn't persuade me that the phenomenon I'm noting here is not a bug.

---

I'm more and more convinced that this is a bug. I just encountered (and reported) the following:

override func viewDidLoad() {
    super.viewDidLoad()
    // Do any additional setup after loading the view.
    async {
        print("howdy")
        await doSomeNetworking()
    }
}
func doSomeNetworking() async {
    print(Thread.isMainThread)
}

This prints howdy and then the second print prints true. But if we comment out the first print, the remaining (second) print prints false!

How can merely adding or removing a print statement change what thread we're on? Surely that's not intended.

---

Historical conclusion: In Swift 6, where Swift Concurrency and async/await have been fully rationalized, the problem no longer arises. func test() is @MainActor by default, because UIViewController is @MainActor, and all lines of it execute on the main actor. If func test() is declared nonisolated, then all lines of it execute off the main actor.

Answer 1

A brief note that since the question was asked, the UIKit classes got marked with @MainActor, so the code in discussion would print true on both occasions. But the problem can still be reproducible with a "regular" class.

Now, getting back to the dicussed behaviour, it's expected, and as others have said its also logical:

• premature optimization is the root of all evil, thread context switches are expensive, so the runtime doesn't easily jump at doing them
• the test function is not entirely in a concurrent context, because the code hops between the MainActor and your class, thus, the Swift runtime doesn't know that it has to get back to the cooperative thread pool.

If you convert your class to an actor, you'll see the behaviour you expect. Here's a tweaked actor based on the code from the question:

actor ThreadTester {
    func viewDidLoad() {
        Task.detached(priority: .userInitiated) {
            await self.test()
        }
    }

    @MainActor func getBounds() async -> CGRect {
        .zero
    }

    func test() async {
        print("test 1", Thread.isMainThread) // false
        let bounds = await self.getBounds()
        print("test 2", Thread.isMainThread) // true
    }
}

Task {
    await ThreadTester().viewDidLoad()
}

You can toggle between actor and class, leaving the other code untouched, and you'll consistently see the two behaviours.

Swift's structured concurrency works best if all entities involved in concurrent operations are already part of the structured concurrency family, as in this case the compiler has all the necessary information to make informed decisions.

Answer 2

Checking on which thread task is running is unreliable since swift concurrency may use same thread across multiple tasks to avoid context switches. You have to use actor isolation to make sure your tasks aren't executed on actor (this applies to any actor along with MainActor).

First of all, actors in swift are reentrant. This means whenever you are making an async call actor suspends current task until the method returns and proceeds to execute other tasks submitted. This makes sure actor is never blocked due to a long-running task. So if you are calling any async call inside test method and fear that the method will be executed on main thread then you have nothing to worry about. Since your ViewController class will be MainActor isolated your code becomes:

override func viewDidLoad() {
    super.viewDidLoad()
    Task {
        await self.test()
    }
}

func getBounds() -> CGRect {
    let bounds = self.view.bounds
    return bounds
}

func test() async {
    // long running async calls
    let bounds = self.getBounds()
    // long running async calls
}

Now if some of your long running calls are synchronous then you have to remove test method from MainActor's isolation by applying nonisolated attribute. Also, creating Task with Task.init inherits the current actor context which is then executed on actor, to prevent this you have to use Task.detached to execute the test method:

override func viewDidLoad() {
    super.viewDidLoad()
    Task.detached {
        await self.test()
    }
}

func getBounds() -> CGRect {
    let bounds = self.view.bounds
    return bounds
}

nonisolated func test() async {
    // long running async calls
    // long running sync calls
    let bounds = await self.getBounds()
    // long running async calls
    // long running sync calls
}

Answer 3

I had the same problem with a function which runs a long task and should always be run on a background thread. Ultimately using the new Swift async await syntax I could not find a easy way based on Task or TaskGroup to ensure this. A Task.detached call will use a different thread as will the Task call itself. If this is called from the MainThread it will be another thread, if not it can be the main thread. Ultimately I found a solution which always works - but looks very "hacky".

1. Make sure your background function is not isolated to the main thread by being part of a class that is a MainActor isolated class (like view controllers)

   nonisolated func iAllwaysRunOnBackground() {}
   

2. Test for main thread and if executed on the main thread call the function again in a Task, wait for execution and return

   nonisolated func iAllwaysRunOnBackground() async throws {
     if Thread.isMainThread {
        async let newTask = Task {
          try await self.iAllwaysRunOnBackground()
        }
       let _ = try await newTask.value
       return 
     }
   
     function body
   }
   

Answer 4

The following formulation works, and solves the entire problem very elegantly, though I'm a little reluctant to post it because I don't really understand how it works:

override func viewDidLoad() {
    super.viewDidLoad()
    Task {
        await self.test2()
    }
}
nonisolated func test2() async {
    print("test 1", Thread.isMainThread) // false
    let bounds = await self.view.bounds // access on main thread!
    print("test 2", bounds, Thread.isMainThread) // false
}

I've tested the await self.view.bounds call up the wazoo, and both the view access and the bounds access are on the main thread. The nonisolated designation here is essential to ensuring this. The need for this and the concomitant need for await are very surprising to me, but it all seems to have to do with the nature of actors and the fact that a UIViewController is a MainActor.

Answer 5

Even if you do the testing to figure out the exact threading behavior of awaiting on @MainActor functions, you should not rely on it. As in @fullsailor's answer, the language explicitly does not guarantee that work will be resumed on the same thread after an await, so this behavior could change in any OS update. In the future, you may be able to request a specific thread by using a custom executor, but this is not currently in the language. See https://github.com/rjmccall/swift-evolution/blob/custom-executors/proposals/0000-custom-executors.md for more details.

Further, it hopefully should not cause any problems that you are running on the main thread. See https://developer.apple.com/videos/play/wwdc2021/10254/?time=2074 for details about how scheduling works. You should not be afraid of blocking the main thread by calling a @MainActor function and then doing expensive work afterwards: if there is more important UI work available, this will be scheduled before your work, or your work will be run on another thread. If you are particularly worried, you can use Task.yield() before your expensive work to give Swift another opportunity to move your work off the main thread. See Voluntary Suspension here for more details on Task.yield().

In your example, it is likely that Swift decided that it is not worth the performance hit of context switching back from the main thread since it was already there, but if the main thread were more saturated, you might experience different behavior.

Edit:

The behavior you're seeing with async let is because this spawns a child task which runs concurrently with the work you are doing. Thus, since that child is running on the main thread, your other code isn't. See https://forums.swift.org/t/concurrency-structured-concurrency/41622 for more details on child tasks.

Answer 6

As I understand it, given that this is all very new, there is no guarantee that asyncDetached must schedule off the main thread.

In the Swift Concurrency: Behind the Scenes session, it's discussed that the scheduler will try to keep things on the same thread to avoid context switches. Given that though, I don't know how you would specifically avoid the main thread, but maybe we're not supposed to care as long as the task makes progress and never blocks.

I found the timestamp (23:18) that explains that there is no guarantee that the same thread will pick up a continuation after an await. https://developer.apple.com/videos/play/wwdc2021/10254/?time=1398