¿Debo anclar un delegado anónimo?

Question

Llamo a CopyFileEx desde una aplicación C# con un delegado anónimo que se pasa al parámetro LPPROGRESS_ROUTINE para recibir notificaciones sobre el progreso de la copia del archivo.

Mi pregunta es, ¿tiene que anclarse el delegado anónimo y por qué (o por qué no)?

Además, ¿Cambia la respuesta si:

1. CopyFileEx no estaba bloqueando.
2. Si pasé en un delegado que no era anónimo.

¡Gracias!

Answer 1

No necesita fijarlo, pero debe mantener una referencia viva mientras la copia esté en progreso.

El pinchazo que recibe el código no administrado está anclado, pero debe asegurarse de que el delegado no sea un recolector de elementos no utilizados, de ahí la referencia.

Answer 2

El delegado no necesita ser fijado. Un objeto administrado es anclado si no puede ser movido por el recolector de basura. Si la información de clasificación es correcta, la capa de clasificación garantizará que se pase un puntero a algo inmóvil.

Sin embargo, el comentario anterior en el que sugiere que una variable local puede mantener al delegado con vida indica un malentendido de la duración de la variable. Lo remito a la especificación, que dice:

La vida útil real de una variable local depende de la implementación. Por ejemplo, un compilador puede determinar estáticamente que una variable local en un bloque solo se usa para una pequeña porción de ese bloque. Usando este análisis, el compilador podría generar código que da como resultado que el almacenamiento de la variable tenga una vida más corta que su bloque contenedor. El almacenamiento contemplada por una variable de referencia local se recupera independientemente del curso de la vida de esa variable de referencia local

En otras palabras, si usted dice:

void M() 
{ 
    Foo foo = GetAFoo(); 
    UnmanagedLibrary.DoSomethingToFoo(foo); 
} 

continuación, se permite decir la fluctuación " ya sabes, veo que ningún código administrado usa foo nuevamente en el momento después de invocar la llamada no administrada, por lo que puedo reclamar agresivamente el almacenamiento de ese objeto desde otro subproceso en ese momento ". Lo que significa que la llamada no administrada puede estar funcionando en el objeto cuando de repente se desasigna en otro hilo.

Esto es particularmente desagradable si Foo tiene un destructor. El código de finalización posiblemente se ejecutará en otro subproceso mientras el objeto esté en uso por la biblioteca no administrada, y solo Dios sabe qué tipo de desastre causará.

En esta circunstancia debe usar KeepAlive para mantener vivo el objeto gestionado. No confíe en una variable local; las variables locales están específicamente documentadas como no garantizadas para mantener las cosas con vida.

Ver http://msdn.microsoft.com/en-us/library/system.gc.keepalive.aspx para más detalles.

Answer 3

De la siguiente msdn parece que tanto pinning como GC.KeepAlive no son necesarios en este caso dado que CopyFileEx es síncrono. Específicamente, dice:

"Por lo general, no tendrá que preocuparse por la duración de los delegados. Cuando transfiera un delegado al código no administrado, el CLR se asegurará de que el delegado esté activo durante la llamada. el código nativo guarda una copia del puntero más allá del lapso de la llamada y tiene la intención de volver a llamar a través de ese puntero más adelante; es posible que necesite usar GCHandle para evitar explícitamente que el recolector de elementos innecesarios recopile el delegado ".

Como CopyFileEx no mantiene un puntero a la función más allá del lapso de la llamada, no deberíamos necesitar llamar a KeepAlive.