-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Add async alternatives to File.ReadAll*, File.AppendAll* and File.WriteAll* #18344
Comments
Note: there's the relevant |
Yup, hence the comment:
😉 |
Here's the async sequences discussion for those that want to follow: dotnet/roslyn#261 |
What does "api-needs-work" mean? Are you interested in a PR for this? Does it need a review first? I'd love to submit a PR, if you can walk me through the process 😄 |
@terrajobst can correct me if I misapplied it; my understanding is that it essentially means "an API proposal that's still being discussed". Some point when the owner (aka @JeremyKuhne) deems it ready for review, the label changes to api-ready-for-review. The process is outlined here: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md |
@stephentoub Thanks. Yeah, I spoke too soon. Found it in the process document right after I asked 😝 I'll await (no pun intended) @JeremyKuhne's response 😄 |
I think it's reasonable to pursue this. Can you flesh out with usage examples and error conditions? I'll mark it for review after that. |
You mean show some sample code calling some of these methods? These are async counterparts to the existing sync methods, so the error conditions would be the same as those, I assume. |
@khellang, yes, sample code. Nothing super complicated, just something to help clearly illustrate the value here. And it is fine to say that we follow the error conditions in the sync methods with a callout to what we do with the CancellationToken. |
OK, an example. Deserializing JSON configuration: public async Task<TConfiguration> ReadConfigurationAsync<TConfiguration>(string path)
{
var json = await File.ReadAllTextAsync(path);
return JsonConvert.DeserializeObject<TConfiguration>(json);
} If you need more examples on usage of
The usage would be exactly the same, only in an async world. |
Also, FYI; the reason I filed this is that I'm getting upvotes on an answer I gave on Stack Overflow almost weekly. The question currently has 7,753 views. |
I amended the proposal to remove the If you want to look at my initial stab at an implementation, see dotnet/corefx@master...khellang:async-file-apis~1. For the underlying (typically |
@JeremyKuhne what else do we need to move this API approval forward? @khellang has implementation ready, waiting just on us ... |
@JeremyKuhne ping? |
@JeremyKuhne @ianhays ping? |
I like these. There are a few places where we have helpers like this that lack async equivalents e.g. ZipFile. I doubt we'll face much resistance to adding these, so lets take it to the next API review session. |
@khellang, how did you decide whether to have an overload that does / does not take a CancellationToken? |
First I wanted all of them to take a Unfortunately, the |
@khellang, thanks.
We don't need to be constrained by what's currently available on StreamReader/StreamWriter... we don't even need to use StreamReader/Writer in the implementation if we don't want to, it's an implementation detail. Let's design the APIs we want and then figure out how to implement them.
What's the limitation with FileStream?
I think it makes sense for there to be an overload for each that takes a CancellationToken. Can you revise it accordingly, based on what you think the ideal is? |
Yeah, I just followed the implementation of what was already there (the sync overloads). Is there a reason why those reader/writer methods don't take a
Nothing. Where I've used the
Alright. I'll change it back to include cancellation tokens for the |
Why the synchronous ones don't? There are very few synchronous methods in the framework that take a CancellationToken; the only ones I can think of are on synchronization primitives, e.g. Wait(CancellationToken). While there is some value in adding sync methods that take CancellationToken, it's generally much less valuable than for the async ones, because of usage patterns but also because of the underlying mechanisms being used and whether they support cancellation. |
No, I mean That's a pretty old issue; https://connect.microsoft.com/VisualStudio/feedback/details/790215/textreader-and-streamreader-read-async-methods-are-missing-a-cancellationtoken-parameter |
Oh... no idea why they were introduced without them ;) |
So... do I smell another API request/proposal/PR? 😉 |
That ones a bit trickier, as there are virtual methods involved; ideally the virtual one would have been the one accepting a CancellationToken. We also don't want things proposed just because there's a theoretical gap, but rather something that is actually needed (I'm not casting judgement on this case, just citing that we only want to spend time on things that actually move the needle). But you're of course welcome to propose something if you think it's important. |
I'm happy with the current state of the proposal, sorry about the dead air. |
Any reason we wouldn't make the cancellation token optional? public static partial class File
{
public static void AppendAllLines(string path, IEnumerable<string> contents);
public static void AppendAllLines(string path, IEnumerable<string> contents, Encoding encoding);
+ public static Task AppendAllLinesAsync(string path, IEnumerable<string> contents, CancellationToken cancellationToken = default(CancellationToken));
+ public static Task AppendAllLinesAsync(string path, IEnumerable<string> contents, Encoding encoding, CancellationToken cancellationToken = default(CancellationToken)));
// ...
} |
Nope. I had them optional, but have been back and forth so much, I guess they got dropped at some point 😝 |
PTAL @ dotnet/corefx#14557 |
See dotnet/corefx#11220 and dotnet/corefx#14557
See dotnet/corefx#11220 and dotnet/corefx#14557
Okay. There's something I'm not getting about the different targets. I thought at least part of the problem was conflicts with mscorlib but it seems from dotnet/coreclr#8690 (comment) that I was wrong on that. I'm giving up. If someone wants to take the changes in the PR above as a starting point, I was pretty happy with the actual implementation and test code. |
I was hoping that the recent engineering changes would have made my difficulty earlier irrelevant, and it seems it has. PTAL at dotnet/corefx#15372. |
Is there a reason why there's no
ReadAll*Async
,AppendAll*Async
andWriteAll*Async
methods onFile
?The existing methods are very convenient and I think it makes sense to have async versions available.
I propose the following additions:
I guess the
ReadLines
methods are candidates for this as well, but I don't know how you'd handle the async enumeration part yet.The text was updated successfully, but these errors were encountered: