Paul Cantrell
@rjmccall @cocoaphony @mergesort @kylebshr @justkwin @jsq
In my (so far limited) experiments with Swift concurrency, I’ve found myself getting tangled in knots fast when I try to use old habits and start my reasoning from “what thread am I on,” and get untangled by thinking about two things:
1. What code wants to let others take a turn and come back later? (Where are the `await`s?)
2. What data must be accessed sequentially, one piece of code at a time? (What isn’t Sendable?)
John McCall
@cocoaphony @mergesort @kylebshr @justkwin @jsq Non-Sendability is the big tool there for when making something an actor isn’t right
Rob Napier
@rjmccall @jsq @kylebshr @justkwin @mergesort I’ve been treating MainActor classes as just another kind of actor. (Maybe that’s confusing terminology?)
But in large programs, “just not sending between concurrent domains” sounds a lot like what we’ve been doing and failing to do correctly (and the problem actors are supposed to help).
Rob Napier
@justkwin @mergesort @kylebshr @jsq @rjmccall true for the community. But Apple is saying explicitly up on stage that it is “the best way to write apps.” So we’re kind of struggling. I’ve recently backed off my push in my team for “no more non-actor classes.” It turned out almost everything I tried to write required hours of research and no definite answer. So now it’s closer to “if you feel like doing the hard work of figuring it out, then it would be nice if you tried some async/await.”
John McCall
@jsq @cocoaphony @kylebshr @justkwin @mergesort I definitely wouldn’t go so far as to say “no non-actor classes”! There are other ways to keep things isolated and thread-safe, like something isolated to the main actor, or just not sending it between concurrent domains
But yeah, we know we owe the community a guidebook here. We’re working on it, and seeing things like is a huge hint about places to flesh out
Quinn “The Eskimo!”
@cocoaphony @mergesort @kylebshr @jsq @rjmccall I’m kinda reluctant to make too many pronouncements about Swift concurrency myself. We as a community are still collectively ironing out the details.
Rob Napier
@mergesort @kylebshr @jsq and yet still, I can’t say 3 sentences about Swift concurrency without making 2 misstatements. Check the replies from @rjmccall and @justkwin who actually know what they’re talking about.
Joe Fabisevich :verified:
@kylebshr @jsq I can't say it better than @cocoaphony here. And if I was being held at gunpoint and these very nerdy captors said “solve this concurrency problem or we shoot but you can phone a friend”, there are few people I'd rather call on than Rob. https://mastodon.social/@cocoaphony/111520060479826953
jesse squires
To clarify it is the structure of the example code that I’m interested in:
1. Action is triggered by user via UI element.
2. Expensive, non-main thread work needs to get dispatched to a background queue.
3. When said work completes, dispatch back to the main thread to update the UI that notifies the user of the result.
So now: write this using structured concurrency.
Don’t tell me “well a ViewController should really only be responsible for…” Yeah, duh. You’re missing the point here.
Kyle Bashour
@jsq @mergesort do you have any thoughts? I think I’ve heard you say you’ve thought about concurrency quite a bit!
jesse squires
Swift challenge for the week:
Given the example code, how do you correctly convert it to use Swift Tasks and Structured Concurrency?
Let's avoid discussing how crappy the example code is — the point is that *a lot* of existing "async” UI code has this general form. This general style/convention of code is everywhere.
I think the first thing folks will reach for is replacing the dispatch queues with `Task { }`, but according to WWDC videos and folks that work on the compiler, that is wrong.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.