{"id":44251,"date":"2024-07-29T16:09:31","date_gmt":"2024-07-29T20:09:31","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44251"},"modified":"2024-07-29T16:09:31","modified_gmt":"2024-07-29T20:09:31","slug":"actor-reentrancy-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/07\/29\/actor-reentrancy-in-swift\/","title":{"rendered":"Actor Reentrancy in Swift"},"content":{"rendered":"

Donny Wals<\/a> (Mastodon<\/a>):<\/p>\n

\n

When you start learning about actors in Swift<\/a>, you’ll find that explanations will always contain something along the lines of “Actors protect shared mutable state by making sure the actor only does one thing at a time”. As a single sentence summary of actors, this is great but it misses an important nuance. While it’s true that actors do only one thing at a time, they don’t always execute function calls atomically<\/a>.<\/p>\n

[…]<\/p>\n

However, when we introduce an async function that has a suspension point the actor will not sit around and wait for the suspension point to resume. Instead, the actor will grab the next message in its “mailbox” and start making progress on that instead. When the thing we were awaiting returns, the actor will continue working on our original function.<\/p>\n

[…]<\/p>\n

Things become trickier when you try and make your actor into a serial queue that runs async tasks. In a future post I’d like to dig into why that’s so tricky and explore possible solutions.<\/p>\n<\/blockquote>\n\n

Holly Borla<\/a>:<\/p>\n

\n

I think something like an async queue should be included in the concurrency library. The AsyncStream<\/code> boilerplate is repeated everywhere for this sort of pattern, and we should make it easier to write because it’s a pattern that a lot of people need when order has to be guaranteed.<\/p>\n<\/blockquote>\n\n

Marcin Krzyzanowski<\/a>:<\/p>\n

\n

what’s worse:<\/p>\n