-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Create helper functions for temporary directories which supports new concurrency features #5532
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
…concurrency features
One of questions is that do library needs at some point to migrate |
we would like to move the process handling to SwiftPM and have it be based on Foundation's process as much as possible. |
@tomerd so can i tackle on this transition? I thought about first slowly migrating bits of code regarding creating temporary file creation and creating series of PRs to create small incremental changes |
Sources/Basics/TemporaryFile.swift
Outdated
/// - Throws: `MakeDirectoryError` and rethrows all errors from `body`. | ||
@available(macOS 12, iOS 15, tvOS 15, watchOS 8, *) | ||
public func withTemporaryDirectory<Result>( | ||
dir: AbsolutePath? = nil, prefix: String = "TemporaryDirectory", removeTreeOnDeinit: Bool = false , _ body: (AbsolutePath) async throws -> Result |
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.
feels like removeTreeOnDeinit should be true by default?
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.
Basically i followed the exact same default argument setup just as in https://github.com/apple/swift-tools-support-core/blob/main/Sources/TSCBasic/TemporaryFile.swift
yes that would be very helpful! |
cc @compnerd |
… to create utf8 strings Formatting fixes
@swift-ci smoke test |
lgtm. @compnerd any feedback? |
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.
One thing that worries me about this is that async functions must be VERY limited on Windows x86_64. There is a missing operation and so it is possible to exhaust the stack if it is extensive. Can we add some sort of mechanism for limiting suspension points if this is going to be adopted?
@compnerd What do you think about exposing Task as result, instead of Result? The api would be something like this: @available(macOS 12, iOS 15, tvOS 15, watchOS 8, *)
public func withTemporaryDirectory<Result>(
dir: AbsolutePath? = nil,
prefix: String = "TemporaryDirectory",
_ body: @escaping (AbsolutePath, @escaping (AbsolutePath) -> Void) async throws -> Result
) throws -> Task<Result, Error> {} it would not be marked as async and we will receive more granular control over the executing of the body making ourself It is not ideal for me in terms of result type, but i guess it can work if need to cancel execution at some point in time. |
Hmm, so the async-ness is encapsulated within the implementation rather than the user's control? I think that would alleviate my concern - with tests on Windows being close, this should be something that we should be able to avoid blowing through the stack. |
Ok, will change semantics of methods and update tests respectively. |
So basically i changed apis to return Task instead of async Result and added a test to showcase an explicit task cancellation |
29da97c
to
d7a7d93
Compare
d7a7d93
to
b386c22
Compare
Also changed Task { return } to task.sleep() in tests
@swift-ci smoke test |
@Overcot this is getting super close. thanks for your effort and patience! |
Changed order of arguments for fileSystem
Resolved all your comments. Please take a look again :) |
@swift-ci smoke test |
lgtm. @abertelrud @neonichu @elsh ? |
@swift-ci please test Windows platform |
thanks @Overcot |
Create helper functions for creating temporary files in order to slowly migrate to async/await based approach to concurrency
Motivation:
There are examples such as in ManifestLoading where async/await approach would be helpful to migrate from completionHandlers to async/await
Modifications:
As mentioned in swiftlang/swift-tools-support-core#321 (comment) it was advised to put this code inside SwiftPM/Basics module in order to not increase amount of code in TSCBasics.
Result:
After that i would also create helper functions for creating temporary files, and maybe start to further investigate what kind of limitations exist to adopt async/await to manifest parsing. As far i can see
Process
also have to be migrated