Skip to content

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

Merged
merged 6 commits into from
Jun 2, 2022

Conversation

Overcot
Copy link
Contributor

@Overcot Overcot commented May 20, 2022

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

@Overcot
Copy link
Contributor Author

Overcot commented May 20, 2022

One of questions is that do library needs at some point to migrate Process and other required types inside SwiftPM? Or i don't need to go into this kind of work?) Was hoping to contribute to spm if possible)

@tomerd
Copy link
Contributor

tomerd commented May 20, 2022

we would like to move the process handling to SwiftPM and have it be based on Foundation's process as much as possible.

@Overcot
Copy link
Contributor Author

Overcot commented May 20, 2022

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

/// - 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
Copy link
Contributor

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?

Copy link
Contributor Author

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

@tomerd
Copy link
Contributor

tomerd commented May 21, 2022

@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

yes that would be very helpful!

@tomerd
Copy link
Contributor

tomerd commented May 21, 2022

cc @compnerd

@tomerd
Copy link
Contributor

tomerd commented May 21, 2022

@swift-ci smoke test

@tomerd
Copy link
Contributor

tomerd commented May 21, 2022

lgtm. @compnerd any feedback?

Copy link
Member

@compnerd compnerd left a 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?

@Overcot
Copy link
Contributor Author

Overcot commented May 23, 2022

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.

@compnerd
Copy link
Member

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.

@Overcot
Copy link
Contributor Author

Overcot commented May 23, 2022

Ok, will change semantics of methods and update tests respectively.

@Overcot
Copy link
Contributor Author

Overcot commented May 23, 2022

So basically i changed apis to return Task instead of async Result and added a test to showcase an explicit task cancellation

@Overcot Overcot force-pushed the temporaryFileAsync branch 2 times, most recently from 29da97c to d7a7d93 Compare May 24, 2022 07:58
@Overcot Overcot force-pushed the temporaryFileAsync branch from d7a7d93 to b386c22 Compare May 24, 2022 07:58
@Overcot
Copy link
Contributor Author

Overcot commented May 25, 2022

@tomerd @compnerd Could you take a look if possible?

Also changed Task { return } to task.sleep() in tests
@tomerd
Copy link
Contributor

tomerd commented May 27, 2022

@swift-ci smoke test

@tomerd
Copy link
Contributor

tomerd commented May 30, 2022

@Overcot this is getting super close. thanks for your effort and patience!

Changed order of arguments for fileSystem
@Overcot
Copy link
Contributor Author

Overcot commented May 30, 2022

@Overcot this is getting super close. thanks for your effort and patience!

Resolved all your comments. Please take a look again :)
Thanks for your support as well!

@tomerd
Copy link
Contributor

tomerd commented May 30, 2022

@swift-ci smoke test

@tomerd
Copy link
Contributor

tomerd commented May 30, 2022

lgtm. @abertelrud @neonichu @elsh ?

@tomerd tomerd self-assigned this May 30, 2022
@compnerd
Copy link
Member

@swift-ci please test Windows platform

@tomerd tomerd merged commit d56abe9 into swiftlang:main Jun 2, 2022
@tomerd
Copy link
Contributor

tomerd commented Jun 2, 2022

thanks @Overcot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants