Remove temp_await [part 1]

[AndrewHoos]

Remove both temp_await and safe_async in favor of broader adoption of async/await

Note:

This change was originally developed as one large PR. To make testing, reviewing, and landing these changes simpler the PR has been broken down into about a dozen individual PRs that are stacked

Motivation:

temp_await is very dangerous API that blocks the current thread and is not marked as unavailable from async methods. The only need for temp_await is because LLBuild only supports non-async methods so any llbuild commands that call async methods have to block waiting.

Because temp_await is liberally spread across the code base there are a number of async methods that may indirectly call into temp_await and indefinitely block a swift concurrency thread. This risks a deadlock. To prevent the deadlock the safe_async method dispatches to a GCD concurrent queue before executing the callback code. Because GCD will create new threads if all existing threads are blocked (unlike swift concurrency) this effectively prevents deadlock risks at the risk of thread explosion.

It would be better if the codebase was free of both the risks of deadlock and thread explosion. Additionally it would be nice if the APIs using temp_await were marked async so that more parts of the code base could safely adopt async/await.

Modifications:

To augment existing memoizer types new async types are added
temp_dir is replaced by unsafe_await which is limited to one used which is called by llbuild
safe_async is replaced by CheckedThrowingContinuation
Multiple protocols have been modified to change their requirements from sync to async
Usage of DispatchSemaphore and DispatchGroup have been replaced with structured concurrency
Many methods that were non-async but used temp_await have been properly marked as async

Result:

No usage of temp_dir or safe_async and only one (safe) usage of unsafe_await from an LLBuild command

[MaxDesiatov]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test windows

[MaxDesiatov]

My concern here is the same as on previous PRs: safe_async uses DispatchQueue.sharedConcurrent under the hood, which can cause thread explosion. IMO instead of using that we need a serial queue for manifest loading, or OperationQueue with a fixed number of threads.

[grynspan]

Pretty sure this can just be a checked continuation, no? Why does it even need to move off the caller at all?

[AndrewHoos]

My concern is that the workspace make use of temp_await which blocks threads so if we call into it from a swift concurrency pool we run the risk of blocking a thread. I know that GCD risks thread explosion, but that is less bad than a deadlocked thread IMO. At the root of this tension is the integration into the LLBuild system which does not support async/await or callbacks. I think I have a plan for how I can limit the unsafe blocking behavior to GCD queue dedicated to builds. Let me take some time to revisit this and make it more holistically address this

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

I don't understand the compiler error from macOS. The body of with*Continuation executes serially on the actor so it should be safe to access isolated state

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[AndrewHoos]

@swift-ci test

[MaxDesiatov]

This LGTM, the remaining uses of safe_async are isolated to CLI commands, which should be acceptable for now. Thanks!

[MaxDesiatov]

@swift-ci test windows