What are the patterns/conventions to expose async closures in one place, and handle getting back to the main queue in another?
Context:
The Xcode warning here makes perfect sense:
"""
Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates.
"""
A dummy implementation of an async throws closure modified an view model directly. (It's annotated MainActor.)
@mattiem Maybe more like: who's responsible to call MainActor.run?
@brentsimmons has this very good heuristic that whoever dispatches on a background queue is responsible to dispatch back to main. Don't leak "being executed on the background queue", and always assume you're on main.
async/await doesn't show where I am in the same way. When I expose an async function, chances are it is being called from a Task (not MainActor), so it's all turned on it's head :)
@ctietze that heuristic does not match how most Apple APIs work. And I think this actually makes sense. The code that has the synchronization requirement should be the one that enforces it. Don’t allow other code to decide what actor/thread you run on.
@mattiem So the takeaway is: when I'm inside an async function, and need to update something on MainActor, I have to tell it to do so. Even if I don't know the current execution context.
Better safe (and explicit) than sorry, more or less?
@ctietze one of the neat things about Swift concurrency is the compiler always knows the context. So you’ll always get a warning if you need to change actors. The idea is you cannot ever get this wrong, no heuristic required.
The idea of hiding thread/queue from callers is still possible, just requires sprinkling around some MainActor annotations. It is, however, “pure overhead” from the compiler’s point of view. But might offer convenience in some situations.
@mattiem Hmmmm I may also be interpreting the async keyword wrong.
That tells the caller to await (on whatever thread). It doesn't say anything about if I actually perform asynchronous work in the function itself.
Xcode's lack of warnings got me thinking: again, this is for a closure parameter, async throws. I pass a function reference. The function doesn't need to be async or throwing; that's also acceptable.
The closure signature doesn't affect the content, really :/
@ctietze you are right: async just means needs an async context, does not have to actually use it. But context requirements like MainActor must be at definition point (where you write the closure signature). This is very different from previous systems, where callers were in charge.
@mattiem So if I want to do the dummy app's view model update, I should annotate the (potentially) async function that's being called as MainActor accordingly?
@ctietze you certainly can do it that way, but I think I’d need to see the code in front of me to be certain. It could be overly-restrictive, but that may be a non-issue, or even desirable in practice.
Thinking about this more and more, I wonder if I should not leak async throws via the action. Maybe that ought to be an implementation detail of the app, talking to the server 🤔
@mattiem So you'd keep the async-ness of the FooAction (better name examples: ReloadTweets, RefreshOrderDetail, ... i.e. something that communicates a potentially failing action with a server round-trip) -- but you'd remove it from the closure and make the async buck stop there?
That's interesting. I haven't thought about the implications of this. It looks like the async-ness is isolated in the action and not spilling out, that could be good 👍
@ctietze it was just the first thing that occurred to me. It does look kinda fire-and-forget, and if you do not need to await, why do it?
But always always always when moving from sync to async you need to think hard about ordering. Free, stand-alone Tasks will not run in the order they are created without explicit work on your part.
I believe I'm fine here w.r.t. ordering. I block the UI before spawning the Task to use the send action (state = .pending) and unlock it with or without error when the response has arrived. So you can't send 2 messages in the UI and get results out of order. (Yet)
@mattiem The recommendation by @twostraws there also is that, if you don't know, better be safe than sorry and use MainActor.run -- so we're all on the same page there, I think?
It's puzzling how I can have a non-async, non-throwing function plugged into an async throwing closure (compiler doesn't complain), and then I don't see that MainActor.run might be necessary.
@ctietze I believe the idea that “if you don’t know” doesn’t make sense. The compiler must know, or actor isolation cannot be enforced. It should only come up for code that should be MainActor-annotated but is not.
Add comment