If you start the first Task with
Task(qos: .background) and the second Task with Task(qos: .userInitiated), the second task will actually start first. And spraying some print(Thread.isMainThread) around the code seems to indicate that everything is running in the main thread at all times. If I understood the proposal, this shouldn't be guaranteed to happen, right? The first task may execute somewhere else, since it's not isolated.I remember Overcast's dev on Twitter saying exactly that.
That's an interesting point. I wonder if the compiler will simply inline very short tasks. My guess is that it won't, and that scheduling is always done dynamically if you manually call
Task (even if it's executed serially after that). On the other hand, if the task is something like a one-liner variable change, the compiler should have enough information to know that it's better to just inline it. Hmm.I can't remember if that was the tweet, but definitely something he tweeted around that time.
import PlaygroundSupport
PlaygroundPage.current.needsIndefiniteExecution = true
actor MyActor {
private var isActive: Bool = false
func doAThing() async {
guard !isActive else { return }
isActive = true
let task = Task { () -> Int in
print("Starting Sub Task")
// Uncomment the below to force actor isolation on this.
//self.isActive = true
return await SomeStruct.doSomething(2)
}
print("Herf")
let someResult = await SomeStruct.doSomething(1)
print("Derf")
print(someResult)
isActive = false
print("Waiting...")
print(await task.result)
}
}
struct SomeStruct {
static func doSomething(_ value: Int) async -> Int {
print("hello \(value)")
try! await Task.sleep(nanoseconds: 10000)
return value
}
}
@MainActor class MyMainActorClass {
private var isActive: Bool = false
func doAThing() async {
guard !isActive else { return }
isActive = true
let task = Task { () -> Int in
print("Starting Sub Task")
//self.isActive = true
return await SomeStruct.doSomething(2)
}
print("Herf")
let someResult = await SomeStruct.doSomething(1)
print("Derf")
print(someResult)
isActive = false
print("Waiting...")
print(await task.result)
}
}
@globalActor
struct MyGlobalActor {
actor ActorType { }
static let shared: ActorType = ActorType()
}
@MyGlobalActor class MyGlobalActorClass {
private var isActive: Bool = false
func doAThing() async {
guard !isActive else { return }
isActive = true
let task = Task { () -> Int in
print("Starting Sub Task")
//self.isActive = true
return await SomeStruct.doSomething(2)
}
print("Herf")
let someResult = await SomeStruct.doSomething(1)
print("Derf")
print(someResult)
isActive = false
print("Waiting...")
print(await task.result)
}
}
enum RunMode {
case actor
case mainActor
case globalActor
}
let runMode: RunMode = .actor
if runMode == .actor {
let actor = MyActor()
Task { @MainActor in
await actor.doAThing()
print("Actor Task complete")
PlaygroundPage.current.finishExecution()
}
print("Actor Task created")
} else if runMode == .globalActor {
Task { @MyGlobalActor in
let actorClass = MyGlobalActorClass()
await actorClass.doAThing()
print("GlobalActor Task Complete")
PlaygroundPage.current.finishExecution()
}
print("GlobalActor Task Created")
} else {
Task { @MainActor in
let mainActorClass = MyMainActorClass()
await mainActorClass.doAThing()
print("MainActor Task Complete")
PlaygroundPage.current.finishExecution()
}
print("MainActor Task Created")
}Oh that makes a lot of sense. I wasn't very aware of the differences between global and non-global actors, so that was very informative. Still think it's going to take some years and a lot of code to be ported from GCD and completion handler based APIs to async/await to fully see the benefits of all this though. Fortunately, it looks like we'll hear more of this since there are a bunch of new talks this WWDC planned for async/await and actors, I'm excited to see what's new.
Same! I learned a lot, writing about it really helps.
NavigationLink(label:value:), which is the new recommendation now that NavigationView is deprecated, the NavigationPath will have the value pushed onto its internal stack, and account for the fact the stack values might look like: enum > struct > NSManagedObject
safeAreaInset on the NavigationStack itself, it still gets attached to the root view rather than the NavigationStack view. But it does mean instead of dropping down all the way to UISplitViewController, I can instead use NavigationSplitView from SwiftUI and just drop down to UIKit on the detail view to attach my accessory view.
Yeah, this is what i saw too. It seems fine, though un programming my brain from decades of \s+[_A-Za-z]\s+ etc, etc. would be tough.
Having written a regex parser once, I always sort of think of it in the tree-like way this regex builder portrays them. I just am so used to the standard perl-like syntax that to me its just a nicer, more compact, representation at the moment. That may change as I get used to the new way. I also am quite used to using string operations to dynamically create the regular expression, and I can see where more verbose and clearer syntax could be very helpful in code maintainability.
Hadn't had time to see that yet! I've been busy with the Metal talks. I had that one bookmarked though, I hope I manage to watch it tomorrow.
Saw the WWDC talk on "Bring multiple windows to your SwiftUI app" hoping they'd improved the Scenes API to be able to check for the foreground window... no luck
