Una cosa a tener en cuenta al usar mono_gchandle_new() que encontré ... mantendrá solo el objeto C# al que hizo referencia en la memoria, pero si ese objeto asigna otros objetos, estos todavía están sujetos a las rutinas de recolección de basura. El hecho de que un objeto que tiene un control, puede tener sus subconjuntos liberados, me ha causado bastante problemas.
Actualmente estoy explorando el sistema mono GC para ver si puedo solucionarlo, por lo que tratará esos objetos como objetos raíz.
Si tiene pocos objetos suficientes (< 4096), puede usar mono_gc_register_root() ... podemos tener miles de objetos, por lo que esto no es bueno para nuestros usos.
ACTUALIZACIÓN: Por lo tanto, era incorrecta al respecto, nos habíamos enganchado en el sistema de asignación de objetos mono y no estábamos pasando correctamente la variable "atómica" en las funciones de asignación de GC. "Atómico" significa algo diferente al GC, no tiene nada que ver con el acceso simultáneo, en realidad significa que la memoria asignada hace referencia a otros objetos (atómico = 0) o no (atómico = 1).
Sé de ['gcroot'] (http://msdn.microsoft.com/en-us/library/481fa11f (VS.80) .aspx) para la implementación de .NET de Microsoft, pero no estoy seguro si esto existirá para Mono. Dudo que esta interfaz de administrado a nativo sea probablemente portátil. –
Tuve el mismo problema y lo resolví teniendo un campo estático en el lado administrado al que asigné el objeto para que nunca se recopile gc. –