-
-
Save christianselig/3596716c876830b2f4683461be15d38a to your computer and use it in GitHub Desktop.
| class ViewController: UIViewController { | |
| override func viewDidLoad() { | |
| super.viewDidLoad() | |
| Task { | |
| // 1️⃣❓ UIViewController is in a MainActor context, so this Task | |
| // will inherit that, so the following pretend expensive call will | |
| // be on the main thread and likely block? | |
| ExpensiveOperationPerformer.doExpensiveLoopAndPrint() | |
| } | |
| Task.detached { | |
| // 2️⃣❓ Is this guaranteed to be off the main thread, so perhaps a | |
| // better way to do a one-off, expensive operation? If it's not | |
| // guaranteed, how would I ensure that? Wrap it in an actor | |
| // instead of a class? What if it's not my class/I can't | |
| // change the code? | |
| ExpensiveOperationPerformer.doExpensiveLoopAndPrint() | |
| } | |
| Task { | |
| ExpensiveOperationPerformer.printSomeNetworkData() | |
| } | |
| } | |
| } | |
| class ExpensiveOperationPerformer { | |
| @MainActor | |
| static func printSomeNetworkData() async throws { | |
| let url = URL(string: "https://example.com/example.json")! | |
| // 3️⃣❓ Will this time consuming network call be guaranteed to NOT | |
| // execute on main, despite the MainActor context? Or will it block? | |
| let (data, response) = try await URLSession.data(for: url) | |
| print(data) | |
| } | |
| static func doExpensiveLoopAndPrint() async { | |
| let upperEnd = 9_999_999_999 | |
| var sum = 0 | |
| for i in 0 ..< upperEnd { | |
| sum += 1 | |
| } | |
| print(sum) | |
| } | |
| } |
Thank you!
@ole, one last question if it's okay. You said:
Even if the URLSession operation ran asynchronously on the main thread (e.g. by using the run loop to manage the network operation), it wouldn't block.
This part confuses me a bit and perhaps it's just terminology. But if instead of a URLSession operation firing, say, I just ran an expensive math operation 1 million times in a for loop, that grinds the UI to a halt (I can't scroll anymore while the operation proceeds) when inside a MainActor context. Isn't that "blocking"? I guess that's what I meant, but maybe I'm mixing up terms here? At some point the operation has to run, right, and if it executes on the main thread it's going to block, no?
Isn't that "blocking"?
I'm not sure if there is a widely accepted definition for "blocking".
Some people use "blocking" only for functions that block a thread while waiting for something else (usually an I/O operation to complete). E.g. Data(contentsOf: URL) will wait synchronously for the data to be loaded from the disk or network. The thread isn't doing anything useful in the meantime and doesn't use CPU time, but still takes up resources (memory and the cost of bringing up a new thread to keep the CPU core busy).
async/await is a really good solution for this use case because it allows the function suspend while it's waiting. So the same thread can do other useful work while the suspended function waits for the I/O operation to complete.
An expensive math operation also keeps its thread occupied, so in that sense the thread is "blocked". But at least it's doing something useful with the CPU.
At some point the operation has to run, right, and if it executes on the main thread it's going to block, no?
Yes. In the context of async/await, you can call await Task.yield() periodically to play nicely with the cooperative scheduling (give waiting tasks a chance to run for a while), but yes, eventually the operation has to do its work. So this kind of CPU-intensive work is not such a good fit for async/await. If you really have a long-running CPU-bound operation and you don't want to put it on the cooperative thread pool, running it on a separate thread or dispatch queue is still a good idea, I think.
Even if the URLSession operation ran asynchronously on the main thread (e.g. by using the run loop to manage the network operation), it wouldn't block.
What I meant by this: The old NSURLConnection(request:delegate:) can perform non-blocking I/O on the main thread. It's perhaps not a perfect analogy because it uses a delegate, but NSURLConnection.init creates the network connection, registers itself with the run loop, and then returns immediately (you could say it "suspends"). The main thread can now do other work and when network packets come in, the run loop notifies the object so it can process the data and call the delegate. No background thread is involved.
In that case the downloading (expensive) is done on a background thread though, right, and the "updating the delegate" (cheap) is handled on the main thread? Or is everything truly done on the main thread and it basically does something akin to a Task.yield() while it waits for the next bytes to arrive? Or perhaps I don't understand how modern networking is done on iOS and it's a separate system entirely?
In that case the downloading (expensive) is done on a background thread though, right, and the "updating the delegate" (cheap) is handled on the main thread?
I'm quite sure no other thread in your app is involved. The actual download is being performed by the networking subsystem of the OS (however that works) and is being managed by the kernel (I think). When new data becomes available, the kernel informs your app that new data on the socket is available. No multithreading required.
Or perhaps I don't understand how modern networking is done on iOS and it's a separate system entirely?
NSURLConnection(request:delegate:) isn't modern networking, but I'd imagine the general principle would be the same for URLSession. The difference might be (I don't know) that URLSession could be using GCD dispatch sources or similar (instead of the run loop) to handle notifications from the socket and then calls your callbacks on a background queue (instead of the thread that started the connection).
Thank you so much for taking the time to explain all this! I've learned a lot! ❤️
❤️
Correction: I tried to prove my claims with some sample code and it turns out NSURLConnection does use a separate thread for something. See the screenshot: when I set a breakpoint in one of the delegate calls, there is a com.apple.NSURLConnectionLoader thread:
It's possible this thread does things like setting up the connection, HTTP parsing, etc. This doesn't invalidate everything I said above because it's definitely possible to write asynchronous networking code without any sort of multithreading (e.g. by using the socket APIs directly), but apparently that's not what NSURLConnection does. Sorry for leading you on the wrong track.
You can also see in the screenshot in the main thread's stack trace that it's using the run loop to invoke the delegate. __CFRunLoopDoSource sounds like it's invoking a callback for a run loop source that has new events (the socket).
Here's my code (macOS Command Line Project in Xcode):
import Foundation
final class Loader: NSObject, NSURLConnectionDataDelegate {
var connection: NSURLConnection? = nil
func start() {
let url = URL(string: "https://google.com")!
connection = NSURLConnection(request: URLRequest(url: url), delegate: self)
}
func connection(_ connection: NSURLConnection, didReceive data: Data) {
print(#function, data)
}
func connection(_ connection: NSURLConnection, didFailWithError error: Error) {
print(#function, error)
}
}
let loader = Loader()
loader.start()
RunLoop.current.run()
Yes. And if you have long-running, non-cooperative pieces of code, it may still be a good idea to execute them outside of the cooperative thread pool (you can still use
DispatchQueue.asyncor even bring up a separateThread). You can usewithCheckedContinuationto bridge between the two worlds.Yes. GCD will bring up more and more threads to keep the thread pool from starving, but this is generally less efficient because threads and thread switching are expensive. The new cooperative thread pool in which the tasks run doesn't do this; it has roughly one thread per core (or possibly less, this isn't a guarantee). If all those threads are busy with blocking work without suspending, the system would become unresponsive.