Open damageboy opened 8 years ago
Thanks for the great suggestion. I agree we should document this. For now, here's a (very quick) summary:
1) On Windows, Sockets uses I/O Completion Ports for async operations, via the CoreCLR thread pool.
2) On Linux, we use non-blocking sockets, and a single thread monitoring for status via epoll
. User callbacks are posted to the CoreCLR thread pool once the I/O operation is complete.
3) On OSX, it works just like Linux, except we're using kqueue
instead of epoll
.
@karelz We think this should be re-routed to perhaps System.IO or other documentation team. Can you pls re-route.
cc: @geoffkizer
@davidsh just change the area label and it will take care of itself :)
And if you want to be really nice, you can tag area owners -- cc @JeremyKuhne @ianhays.
This doesn't sound like a System.IO issue to me. Sounds like it's squarely about Sockets. Am I missing something?
Perhaps a detailed blog post about our Sockets model/implementation would be useful.
Hey all, I'm trying to dive into the sources for async sockets on Posix/Linux.. And I just want to make sure that I'm not imagining... In posix based systems the async sockets actually queue work items into the ThreadPool, and the actual IO is performed in a synchronous (maybe non-blocking) manner?
Is this right? I assume that this is a very big split from how things are done on a native win32 system...
I would appreciate any sort of clarification on this matter from someone well aware of the actual implementation
I also think the documentation could benefit from a more detailed explanation of how async I/O works in different scenarios (OS)... I would be more than happy to submit a PR for the documentation, but I just want to make sure I'm reading the situation the right way
Basically people doing async IO need to be aware of how the .NET idioms map to the actual OS... Better documentation for Windows/Linux/OSX should be very useful