OpenRead asynchronously





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







5















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?










share|improve this question

























  • 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




















5















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?










share|improve this question

























  • 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
















5












5








5


2






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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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





















  • 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














1 Answer
1






active

oldest

votes


















8














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.






share|improve this answer
























  • 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 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





    @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












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
});


}
});














draft saved

draft discarded


















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









8














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.






share|improve this answer
























  • 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 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





    @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
















8














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.






share|improve this answer
























  • 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 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





    @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














8












8








8







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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 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





    @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



















  • 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 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





    @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

















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




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







這個網誌中的熱門文章

Tangent Lines Diagram Along Smooth Curve

Yusuf al-Mu'taman ibn Hud

Zucchini