OpenRead asynchronously
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I'm using the following C# code to read a tiny text file over a network share:
string fileContent;
using (var stream = File.OpenRead(filePath))
using (var reader = new StreamReader(stream, FileEncoding))
{
fileContent = await reader.ReadToEndAsync();
}
Even though the text file is very small (less than 10 KB) this operation sometimes takes ~7 seconds to run. When that happens, I've noticed most of the time is spent on
File.OpenRead(filePath)
This is probably due to Windows having to resolve the file share and to acquire locks on the file over the network. As that method call is not asynchronous, this is blocking my current thread for several seconds.
Is there a safe way to read a file from disk asynchronously that also performs OpenRead asynchronously?
c# file-io async-await
add a comment |
I'm using the following C# code to read a tiny text file over a network share:
string fileContent;
using (var stream = File.OpenRead(filePath))
using (var reader = new StreamReader(stream, FileEncoding))
{
fileContent = await reader.ReadToEndAsync();
}
Even though the text file is very small (less than 10 KB) this operation sometimes takes ~7 seconds to run. When that happens, I've noticed most of the time is spent on
File.OpenRead(filePath)
This is probably due to Windows having to resolve the file share and to acquire locks on the file over the network. As that method call is not asynchronous, this is blocking my current thread for several seconds.
Is there a safe way to read a file from disk asynchronously that also performs OpenRead asynchronously?
c# file-io async-await
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09
add a comment |
I'm using the following C# code to read a tiny text file over a network share:
string fileContent;
using (var stream = File.OpenRead(filePath))
using (var reader = new StreamReader(stream, FileEncoding))
{
fileContent = await reader.ReadToEndAsync();
}
Even though the text file is very small (less than 10 KB) this operation sometimes takes ~7 seconds to run. When that happens, I've noticed most of the time is spent on
File.OpenRead(filePath)
This is probably due to Windows having to resolve the file share and to acquire locks on the file over the network. As that method call is not asynchronous, this is blocking my current thread for several seconds.
Is there a safe way to read a file from disk asynchronously that also performs OpenRead asynchronously?
c# file-io async-await
I'm using the following C# code to read a tiny text file over a network share:
string fileContent;
using (var stream = File.OpenRead(filePath))
using (var reader = new StreamReader(stream, FileEncoding))
{
fileContent = await reader.ReadToEndAsync();
}
Even though the text file is very small (less than 10 KB) this operation sometimes takes ~7 seconds to run. When that happens, I've noticed most of the time is spent on
File.OpenRead(filePath)
This is probably due to Windows having to resolve the file share and to acquire locks on the file over the network. As that method call is not asynchronous, this is blocking my current thread for several seconds.
Is there a safe way to read a file from disk asynchronously that also performs OpenRead asynchronously?
c# file-io async-await
c# file-io async-await
edited Apr 2 '15 at 11:03
svick
177k40298417
177k40298417
asked Apr 2 '15 at 1:32
roimroim
2,21621727
2,21621727
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09
add a comment |
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09
add a comment |
1 Answer
1
active
oldest
votes
No, unfortunately this is missing in the Win32 API. Device drivers do have the notion of an "asynchronous open", so the infrastructure is there; but the Win32 API does not expose this functionality.
Naturally, this means that .NET can't expose that functionality, either. You can, however, use a "fake asynchronous" operation - i.e., wrap your file read within a Task.Run
, so that your UI thread isn't blocked. However, if you're on ASP.NET, then don't use Task.Run
; just keep the (blocking) file open as it is.
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal ofasync
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to useTask.Run
, which just blocks a thread pool thread so the UI thread is not blocked.
– Stephen Cleary
Apr 2 '15 at 10:12
4
@roim: The main goal ofasync
on ASP.NET is to free up thread pool threads so the server can scale; usingTask.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.
– Stephen Cleary
Apr 2 '15 at 10:15
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f29403597%2fopenread-asynchronously%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
No, unfortunately this is missing in the Win32 API. Device drivers do have the notion of an "asynchronous open", so the infrastructure is there; but the Win32 API does not expose this functionality.
Naturally, this means that .NET can't expose that functionality, either. You can, however, use a "fake asynchronous" operation - i.e., wrap your file read within a Task.Run
, so that your UI thread isn't blocked. However, if you're on ASP.NET, then don't use Task.Run
; just keep the (blocking) file open as it is.
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal ofasync
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to useTask.Run
, which just blocks a thread pool thread so the UI thread is not blocked.
– Stephen Cleary
Apr 2 '15 at 10:12
4
@roim: The main goal ofasync
on ASP.NET is to free up thread pool threads so the server can scale; usingTask.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.
– Stephen Cleary
Apr 2 '15 at 10:15
|
show 1 more comment
No, unfortunately this is missing in the Win32 API. Device drivers do have the notion of an "asynchronous open", so the infrastructure is there; but the Win32 API does not expose this functionality.
Naturally, this means that .NET can't expose that functionality, either. You can, however, use a "fake asynchronous" operation - i.e., wrap your file read within a Task.Run
, so that your UI thread isn't blocked. However, if you're on ASP.NET, then don't use Task.Run
; just keep the (blocking) file open as it is.
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal ofasync
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to useTask.Run
, which just blocks a thread pool thread so the UI thread is not blocked.
– Stephen Cleary
Apr 2 '15 at 10:12
4
@roim: The main goal ofasync
on ASP.NET is to free up thread pool threads so the server can scale; usingTask.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.
– Stephen Cleary
Apr 2 '15 at 10:15
|
show 1 more comment
No, unfortunately this is missing in the Win32 API. Device drivers do have the notion of an "asynchronous open", so the infrastructure is there; but the Win32 API does not expose this functionality.
Naturally, this means that .NET can't expose that functionality, either. You can, however, use a "fake asynchronous" operation - i.e., wrap your file read within a Task.Run
, so that your UI thread isn't blocked. However, if you're on ASP.NET, then don't use Task.Run
; just keep the (blocking) file open as it is.
No, unfortunately this is missing in the Win32 API. Device drivers do have the notion of an "asynchronous open", so the infrastructure is there; but the Win32 API does not expose this functionality.
Naturally, this means that .NET can't expose that functionality, either. You can, however, use a "fake asynchronous" operation - i.e., wrap your file read within a Task.Run
, so that your UI thread isn't blocked. However, if you're on ASP.NET, then don't use Task.Run
; just keep the (blocking) file open as it is.
answered Apr 2 '15 at 1:47
Stephen ClearyStephen Cleary
290k49485608
290k49485608
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal ofasync
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to useTask.Run
, which just blocks a thread pool thread so the UI thread is not blocked.
– Stephen Cleary
Apr 2 '15 at 10:12
4
@roim: The main goal ofasync
on ASP.NET is to free up thread pool threads so the server can scale; usingTask.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.
– Stephen Cleary
Apr 2 '15 at 10:15
|
show 1 more comment
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal ofasync
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to useTask.Run
, which just blocks a thread pool thread so the UI thread is not blocked.
– Stephen Cleary
Apr 2 '15 at 10:12
4
@roim: The main goal ofasync
on ASP.NET is to free up thread pool threads so the server can scale; usingTask.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.
– Stephen Cleary
Apr 2 '15 at 10:15
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
HOLY CRAP. Is there a voice to get that added to the Win 10 API?
– Aron
Apr 2 '15 at 1:50
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
I'm not on ASP.NET, but I would be interested in knowing why that would be a bad choice there specifically. Any references?
– roim
Apr 2 '15 at 3:31
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@aron: Not to my knowledge; feel free to open a UserVoice issue. I believe that async close is also possible, but may be more difficult to model.
– Stephen Cleary
Apr 2 '15 at 10:10
@roim: The main goal of
async
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to use Task.Run
, which just blocks a thread pool thread so the UI thread is not blocked.– Stephen Cleary
Apr 2 '15 at 10:12
@roim: The main goal of
async
on a client UI is to free up the UI thread so the app is more responsive; it's acceptable (but not ideal) to use Task.Run
, which just blocks a thread pool thread so the UI thread is not blocked.– Stephen Cleary
Apr 2 '15 at 10:12
4
4
@roim: The main goal of
async
on ASP.NET is to free up thread pool threads so the server can scale; using Task.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.– Stephen Cleary
Apr 2 '15 at 10:15
@roim: The main goal of
async
on ASP.NET is to free up thread pool threads so the server can scale; using Task.Run
, would force a context switch and then use up one thread pool thread to free up another thread pool thread. A net loss. I've written about it a bit in an MSDN article and on my blog.– Stephen Cleary
Apr 2 '15 at 10:15
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f29403597%2fopenread-asynchronously%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you tried copying or moving the file to local first and then reading it? Just try it if you haven't already to test it, that may show some other possible problem in network if that is the case.
– Oğuz Sezer
Apr 2 '15 at 11:09