{"action":"created","issue":{"url":"https://api.github.com/repos/dotnet/corefx/issues/5044","labels_url":"https://api.github.com/repos/dotnet/corefx/issues/5044/labels{/name}","comments_url":"https://api.github.com/repos/dotnet/corefx/issues/5044/comments","events_url":"https://api.github.com/repos/dotnet/corefx/issues/5044/events","html_url":"https://github.com/dotnet/corefx/issues/5044","id":122820116,"number":5044,"title":"Discussion: advantage to using sync over async for I/O?","user":{"login":"roji","id":1862641,"avatar_url":"https://avatars.githubusercontent.com/u/1862641?v=3","gravatar_id":"","url":"https://api.github.com/users/roji","html_url":"https://github.com/roji","followers_url":"https://api.github.com/users/roji/followers","following_url":"https://api.github.com/users/roji/following{/other_user}","gists_url":"https://api.github.com/users/roji/gists{/gist_id}","starred_url":"https://api.github.com/users/roji/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/roji/subscriptions","organizations_url":"https://api.github.com/users/roji/orgs","repos_url":"https://api.github.com/users/roji/repos","events_url":"https://api.github.com/users/roji/events{/privacy}","received_events_url":"https://api.github.com/users/roji/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-12-17T20:47:46Z","updated_at":"2015-12-22T10:00:38Z","closed_at":null,"body":"Continuation of discussion from #4868 \r\n\r\n>>Without AuthenticateAsClient(), Open() must resort to calling an async method internally, which means that it's no longer purely synchronous...\r\n>The code above is as synchronous as the old implementation. When you call synchronous I/O on something like NetworkStream, internally, the thread will be waiting on an event for the operation to finish. Even more broadly: in reality there is no such thing as synchronous I/O in Windows.\r\n\r\nThanks for this detail. I was aware that at least in some cases sync methods actually perform async operations under the hood.\r\n\r\nHowever, coming from the Unix universe, it doesn't seem to hold that there's \"no such thing as synchronous I/O\" at least at the kernel level: I would expect .NET I/O operations to map to simple sync I/O system calls such as write and read. Also, the implementation details underlying async operations across platforms may make sync I/O more attractive at least in some cases (i.e. is async I/O implemented efficiently on Linux with mono, or with coreclr for that matter?). I admit I'm just asking questions, I don't have enough solid knowledge here.\r\n\r\nRegardless of these questions, and I said back in #4868, there's something odd about removing such a specific sync API (SslStream.AuthenticateAsClient) for such a general \"sync I/O is bad\" argument, without touching any other sync API. In other words, I'd expect either all sync APIs to stay for backwards compatibility or for a more sweeping removal of sync I/O APIs."},"comment":{"url":"https://api.github.com/repos/dotnet/corefx/issues/comments/166571127","html_url":"https://github.com/dotnet/corefx/issues/5044#issuecomment-166571127","issue_url":"https://api.github.com/repos/dotnet/corefx/issues/5044","id":166571127,"user":{"login":"roji","id":1862641,"avatar_url":"https://avatars.githubusercontent.com/u/1862641?v=3","gravatar_id":"","url":"https://api.github.com/users/roji","html_url":"https://github.com/roji","followers_url":"https://api.github.com/users/roji/followers","following_url":"https://api.github.com/users/roji/following{/other_user}","gists_url":"https://api.github.com/users/roji/gists{/gist_id}","starred_url":"https://api.github.com/users/roji/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/roji/subscriptions","organizations_url":"https://api.github.com/users/roji/orgs","repos_url":"https://api.github.com/users/roji/repos","events_url":"https://api.github.com/users/roji/events{/privacy}","received_events_url":"https://api.github.com/users/roji/received_events","type":"User","site_admin":false},"created_at":"2015-12-22T10:00:38Z","updated_at":"2015-12-22T10:00:38Z","body":"One additional reaction to something you said before:\r\n\r\n>> One disadvantage of async I/O is the pressure put on the thread pool...\r\n\r\n> Pressure on a thread-pool shows poor design in the Async system. Ideally you should always try to keep the number of threads equal to the number of CPUs. Everything above that is going to add overheads of thread switching and memory consumption. This can be achieved by using TPL Async. The concurrency level can be controlled via the TaskScheduler class.\r\n\r\nThat certainly seems true in a single application that's totally within my control, but what happens in a large complex concurrent application using several 3rd-party libraries which themselves may or may not rely on the TP? It can easily become complicated to to manage this and understand the exact TP needs across everything...\r\n\r\nAt the end of the day, async APIs introduce a dependency on a global shared resource (the TP) which sync APIs don't have...\r\n\r\nAny comments on all this?"}}