c# - valid - sandcastle visual studio

¿Dónde/cómo puedo encontrar si una clase.net usa IOCP? (3)

Actualizar

Hice una pregunta incorrecta, reformulada (basada en la excelente información sobre respuestas y comentarios):

¿Existe alguna buena fuente para que las operaciones asincrónicas de .net sean asincrónicas reales, por lo tanto, IOCP o async (superpuestas)? ¿Hay alguna manera rápida de averiguar si varias clases lo están haciendo?

Ejemplo de no confiar ciegamente en los desarrolladores de framework

El punto de partida natural para crear un FileStream es el método estático File.Open (), cuya documentación no menciona nada sobre la sincronicidad del FileStream que se crea. Tampoco le permite proporcionar FileOptions (que se utilizan para especificar el indicador mágico FileOptions.Asynchronous).
En cambio, FileStream se crea con FileOptions.None. Las operaciones asincrónicas se simulan silenciosamente mediante la implementación obligada de la clase base de Stream, que simplemente ajusta el método de sincronización correspondiente en un delegado y lo invoca en el grupo de subprocesos mediante el método BeginInvoke ().
Esta es una desviación de la filosofía de diseño del ''pozo del éxito'' habitual, donde todo en .NET parece funcionar como usted cree que sería, sin necesidad de leer de cerca la documentación y / o descubrir gradualmente capturas poco claras y errores a lo largo del tiempo.

He estado tratando de encontrar información sobre el uso de Puertos de finalización de IO en .NET .

¿Hay alguna forma de saber si una clase .NET determinada está utilizando puertos de terminación IO ? (sin tener que ejecutar algunas pruebas cada vez que use una nueva clase).

Probé los documentos msdn para algunas clases y métodos, y no pude encontrar nada en él.

Aún mejor, sería si hay alguna lista con una lista de clases usando IOCP.

En general, BCL solo ofrece API asíncronas si se implementan utilizando async IO respaldado por el kernel de Windows. La exposición de los métodos asíncronos que no usan kernel-IO asíncrono sería el anti-patrón async-sync sincronizado que seguramente conocen los diseñadores de BCL. Esto no solo sería inútil, sino dañino para el rendimiento y engañoso. Ellos no hacen eso.

Windows puede hacer asincronizar IO usando IOCP o usando IO superpuesto regular. Ambos son eficientes, asíncronos y, por lo tanto, más escalables que el bloqueo de IO.

Todo esto es transparente para ti. Confíe en que la sincronización sea verdaderamente asincrónica y que la sincronización sea verdaderamente sincronizada.

Si tiene dudas, mire debajo del capó con Reflector. Cada vez que he hecho esto, he encontrado confirmado lo que acabo de decir. Todavía tengo que ver un caso diferente.

Lo que se ve con Reflector es que el BCL llama a las versiones asíncronas de las API de Win32 relevantes. Como ejemplo, examinaré los archivos y los sockets:

FileStream.BeginRead llama indirectamente a Win32Native.ReadFileNative con un puntero a una estructura NativeOverlapped . El puntero se obtiene llamando a Overlapped.Pack . La devolución de llamada de finalización se almacena de esa manera. Es imposible seguir cómo se llama a la devolución de llamada con Reflector porque esa parte existe en la parte nativa de la CLR. No puedo decir si IOCP está en uso, pero puedo decir que Async IO está en uso.
Socket.BeginRead llama indirectamente a WSARecv . El código es bastante complejo. El BCL parece ser capaz de usar IO superpuesto así como IOCP dependiendo del sistema operativo. El control se realiza en Socket.InitializeSockets . La decisión sobre qué tipo de IO usar se almacena en Socket.UseOverlappedIO . Si esa variable es falsa, finalmente se llama a Socket.BindToCompletionPort .

Entonces, para Sockets es claramente IOCP en sistemas operativos modernos. Para archivos que no puedo decir.

Personalmente, no estoy particularmente interesado en qué tipo de async IO se utiliza, siempre que no sea bloqueante. Este es el caso.

Los puertos de terminación de E / S son un fuerte detalle de implementación de la plataforma, uno del que .NET no puede depender ciegamente para estar disponible. Y no es así, deja que el host CLR implemente el pegamento para el sistema operativo que lo soporta. La interfaz de alojamiento subyacente es IHostIoCompletionManager , disponible desde .NET 2.0

Entonces, si quiere una garantía dura de que realmente se usen, entonces necesita obtener la fuente del host CLR que usa. Esto es difícil de conseguir, hay muchos y debe solicitar un trabajo en Microsoft para obtener acceso a la fuente. Solo el host SSCLI20 está disponible en origen, está fechado y cubre solo el host predeterminado. El cual fue modificado por sí mismo para permitir que el PAL provea el puerto de E / S de finalización, seguramente no presente realmente en los hosts reales de CLR con los que alguna vez se ejecutaría.

No fue específico sobre qué plataformas considera. Algunas estimaciones:

ASP.NET: sí, los puertos de terminación de E / S son un gran problema para los zócalos
SQL Server: muy probable, pero no slamdunk, tiene una habilidad especial para hacer las cosas de manera diferente
Escritorio: sí, para cualquier versión .NET> = 2.0 que se ejecute en la rama NT
Compacto: definitivamente no
Micro: definitivamente no
XBox: poco probable, los detalles del sistema operativo son un gran misterio
Silverlight: CoreCLR.dll de la versión de Windows lo usa pero no ThreadPool.BindHandle
Phone7: similar a Silverlight
Phone8: gran misterio, probablemente.

Enfatizando que estas son meras conjeturas educadas que no están respaldadas por pruebas. La pregunta es bastante extraña, no es como si tuvieras una alternativa si descubres que la E / S asíncrona fue realizada por E / S superpuestas.

De acuerdo con mi experiencia, las siguientes API basadas en IOCP:
FileStream: BeginWrite / BeginRead. NOTA: debe pasar FileOptions.Asynchronous cuando crea FileStream
DNS: BeginGetHostByName / BeginResolve
Zócalo: BeginAccept / BeginConnect / BeginReceive, etc.
WebRequest: BeginGetRequestStream / BeginGetResponse
SqlCommand: BeginExecuteReader / BeginExecuteNonQuery etc. Debe establecer AsynchronousProcessing como verdadero (de manera predeterminada, es falso).
WebServcie: BeginXXX en WebServiceProxy generado por WCF e InvokeAsync en ClientBase