-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Avoid using temp_await
on loadRootPackage
#7009
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -8803,13 +8800,15 @@ final class WorkspaceTests: XCTestCase { | |||
|
|||
let observability = ObservabilitySystem.makeForTesting() | |||
let wks = try workspace.getOrCreateWorkspace() | |||
XCTAssertNoThrow(try temp_await { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
XCTAssertNoThrow
doesn't support async
🥲
@swift-ci test |
1 similar comment
@swift-ci test |
@swift-ci test |
@swift-ci test windows |
Follow up to #7009, which provides the detailed motivation: we should avoid `temp_await` as it can lead to deadlocks when combined with Swift Concurrency.
Follow up to #7009, which provides the detailed motivation: we should avoid `temp_await` as it can lead to deadlocks when combined with Swift Concurrency.
@compnerd would you be able to confirm that this change is fine from the perspective of Swift Concurrency support on Windows? |
I think that as long as we restrict this to 5.10/5.11 it should be okay. Of course we should run through the test suite as well. |
There are no plans to backport it to 5.9. How far are we from enabling the test suite on Windows CI? Until then is the only way to test it on Windows to build latest 5.10 locally and to run |
@swift-ci test |
7b28181
to
1d5922d
Compare
@swift-ci test |
Follow up to #7009, which provides the detailed motivation: we should avoid `temp_await` as it can lead to deadlocks when combined with Swift Concurrency. --------- Co-authored-by: Yim Lee <yim_lee@apple.com>
@swift-ci test |
@swift-ci test windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It all looks great except for checkPrecomputeResolution
. I don't see why the checkPrecomputeResolution
method needs to have a closure. Closures normally are for async callbacks, context managers, or optional extra validation (e.g. assert throws). It seems like that API should get reworked to by natively async
@swift-ci test |
@swift-ci test windows |
@@ -71,7 +69,7 @@ extension SwiftPackageTool { | |||
let args = [swiftFormat.pathString] + formatOptions + [packagePath.pathString] + paths | |||
print("Running:", args.map{ $0.spm_shellEscaped() }.joined(separator: " ")) | |||
|
|||
let result = try TSCBasic.Process.popen(arguments: args) | |||
let result = try await TSCBasic.Process.popen(arguments: args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked, but I wonder if this is actually non-blocking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I'm cleaning that up on TSC side now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrapped that with a concurrent queue in swiftlang/swift-tools-support-core#450
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤣 ask me if I have deadlocked the swift concurrency pool before...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to use the safe_async wrapper until that lands?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've enabled auto-merge on that one, so I don't think there will be a significant amount of time when this PR is merged, but one in TSC isn't.
@swift-ci test windows |
1 similar comment
@swift-ci test windows |
Follow up to #7009, which provides the detailed motivation: we should avoid `temp_await` as it can lead to deadlocks when combined with Swift Concurrency.
This reverts commit 6bed023.
Motivation:
Using locks to convert asynchronous functions to synchronous is dangerous, since this can deadlock the Swift Concurrency thread pool. Unfortunately,
temp_await
(AKAtsc_await
) function utilizes exactly this approach.As SourceKit-LSP starts adopting Swift Concurrency (swiftlang/sourcekit-lsp#850), we should avoid using
temp_await
in our codebase and make the callers of correspondingasync
or callback-taking functions themselvesasync
. Otherwise there's a risk of deadlocks in SourceKit-LSP itself, since their Swift Concurrency tasks may be blocked by our uses oftemp_await
under the hood. We have ~60 uses oftemp_await
in our codebase, carefully removing them in small portions will reduce the potential disruption.Modifications:
loadRootPackage
already has anasync
overload inWorkspace
. Converted callers in SwiftPM commands to useAsyncSwiftCommand
protocol instead ofSwiftCommand
. Also, test cases were madeasync
too.Result:
Reduced the number of
temp_await
uses inSource
.