4

I know that .Net Core can run on Mac and Unix.

What happens to Win32 classes like the overlapped I/O and how do an I/O request packet translate into Unix?

If I correctly understand, those win32 classes and structures are the basis of async/await with P/Invoke I/O instructions.

  • Those are not the basis of async await at all. Those things are completely unrelated. Async/await is a pure language feature. Overlapping IO is a windows specific way of doing asynchronous IO. The implementation of async file reading and sockets on windows *do* use IOCP but that's a very very very deep implementation detail. – davidfowl Aug 25 '17 at 07:58
  • @davidfowl first, *the fact that "there is no thread"* is not an implementation detail (there is a lot of emphasis about the correct usage of async, as opposite to task creation or to cpu bound activities), do you agree on this? If *it* is not (and using IOCP is one of the implicit assumptions for the correct usage scenario on windows), then I'm looking for an equivalent implementation detail on different OS, where Net Core (with its language features) can run... –  Aug 26 '17 at 08:44
  • Just to reinforce the concept behind my question, you can find similar reasoning and **expectations** in another question, titled "*Does calling asynchronous Task based WCF method utilize the I/O completion port ...*": +7 votes there confirm that the `async` language feature and a corresponding "`IOCP`-*like*"/"thread *efficient*" implementation are not at all unrelated things. –  Aug 26 '17 at 13:39
  • No I don't agree with it. You're talking about things in the same realm but mushing them together will only confuse things. I know what you're asking but I'm being pedantic because async await really has nothing to do with IOCP fundamentally. You just want to know how IO is implemented on *nix platforms in CoreCLR. Using epoll on unix and kqueue on OSX/BSD. That's the short answer. The actual details are *much* more involved (and are also an implementation detail) – davidfowl Aug 26 '17 at 17:11
  • @davidfowl it's not me mushing anything, from [msdn](https://blogs.msdn.microsoft.com/csliu/2009/08/04/inside-scalable-io-model-in-sync-async-way/) "*The basic motivation for Async I/O is to boost performance*", aka a [C10K problem](https://coelhorjc.wordpress.com/2014/12/18/using-non-blocking-and-asynchronous-io-ck10-problem-in-linux-and-windows-with-epool-iocp-aiolibaio-libeventlibevlibuv-boost-asio/amp/): what iocp, epoll, kqueue, etc are supposed to solve on the other hand. Yes, you understood my question: you could write a little more extended answer, with just an example on nix platform. –  Aug 26 '17 at 18:59
  • > The basic motivation for Async I/O is to boost performance That doesn't have anything to do with async/await though. AKA it is *NOT* the basis, nor is it required for async/await to function. Async/await is just C#'s represenation of co-routines. – davidfowl Aug 26 '17 at 19:02
  • @davidfowl just click on the `async-await` tag |> learn more... |> resources |> the 5th article from the top is the one I'm speaking about and the one I've referenced in my question. Similar explanation can be found under [Microsoft doc. "Async in depth"](https://learn.microsoft.com/en-us/dotnet/standard/async-in-depth). Either way you'd be better off sharing your definition and your replies in an answer - which can be more visible and more appreciated by the community than these comments. Thanks, kind regards. –  Aug 27 '17 at 17:26

1 Answers1

3

There is a platform abstraction layer implemented by the CoreCLR that handles the implementation using the appropriate OS capabilities for asynchronous I/O. For example, on platforms that support kevent (such as FreeBSD and macOS), they will use kqueue for queuing and raising I/O callbacks. This is one of the many areas, but a good place to start understanding the CoreCLR and tie it back to the managed implementations.

https://github.com/dotnet/coreclr/blob/dd1e7ab81221127e47d59052c51c09921007d607/src/pal/src/synchmgr/synchmanager.cpp#L2103

DaveC
  • 364
  • 3
  • 10
  • How is this Synchronization Manager related to C# async/await or to F# async computation expression? At the beginning of synchmanager.cpp they write "*We use the synchronization manager's worker thread to handle process termination requests*" which doesn't seem related to this. –  Aug 22 '17 at 10:17
  • @user1892538 that's referring to the Synchronization Manager's worker thread itself, not the whole Synchronization Manager. – DaveC Aug 22 '17 at 11:15
  • Ok, so I assume the APC part is the relevant one, how can I be sure that the high leve async is implemented through this? –  Aug 22 '17 at 11:39
  • Also the fact that Linux doesn't support neither IOCP nor async IO - but a different ["*notify on ready*" model](https://stackoverflow.com/a/2821025/6996876) - seems relevant to the answer: "*epoll (and kqueue) are products of Unix's approach to I/O, which is synchronous by design*" (from [HN](https://news.ycombinator.com/item?id=12341909)). –  Aug 26 '17 at 14:58
  • @user1892538 giving a complete answer here will take a huge exploration of the platform abstraction layer, a tiny bit of which I linked in my answer. I'll remove my answer, since maybe someone else can go through the whole stack for you. – DaveC Aug 26 '17 at 15:16
  • Hopefully, I don't think you can remove an accepted, upvoted answer (but you can remove the above comment instead). –  Aug 26 '17 at 15:20
  • @user1892538 guess not. Maybe someone that wants to explain the abstraction layer will make a better answer. Or you could go through it and piece things together and post one. – DaveC Aug 26 '17 at 15:22