{"id":44662,"date":"2024-08-29T15:18:48","date_gmt":"2024-08-29T19:18:48","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44662"},"modified":"2024-08-29T15:18:48","modified_gmt":"2024-08-29T19:18:48","slug":"calling-async-code-synchronously-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/08\/29\/calling-async-code-synchronously-in-swift\/","title":{"rendered":"Calling async Code Synchronously in Swift"},"content":{"rendered":"

Wade Tregaskis<\/a>:<\/p>\n

I find my hand is often forced by APIs I don’t control (most often Apple’s APIs). e.g. data source or delegate callbacks that are synchronous and require you to return a value, but in order to obtain that value you have to run async code (perhaps because yet again that’s all you’re given by 3rd parties, or because that code makes sense to be async and is used happily as such in other places and you don’t want to have to duplicate it in perpetuity just to have a sync version).<\/p>

If that asynchronosity is achieved through e.g. GCD<\/a> or NSRunLoop<\/a> or NSProcess<\/a> or NSTask<\/a> or NSThread<\/a> or pthreads<\/a>, it’s easy. There are numerous ways to synchronously wait on their tasks. In contrast, Swift Concurrency<\/a> really<\/em> doesn’t want you to do this. The language and standard library take an adamant idealogical position on this – one which is unfortunately impractical; a spherical chicken in a vacuum<\/a>.<\/p>

Nonetheless, despite Swift’s best efforts to prevent me, I believe I’ve come up with a way to do this.<\/p>\n

[…]<\/p>\n

Do not call this from a thread used by Swift Concurrency (e.g. an actor, including global actors like MainActor<\/code>) if the closure - or anything it calls transitively via await<\/code> - might be bound to that same isolation context. Doing so may result in deadlock.<\/p><\/blockquote>\n\n

Previously:<\/p>\n