Gestión de memoria para un marco de plugin Delphi basado en TInterfacedClass

Question

Para un marco de plugin del lado del servidor Me gustaría implementar DLL que expongan un método RegisterPlugin que devuelve una referencia de clase (TInterfacedClass).

La aplicación de host luego crea la (s) instancia (s) de esta clase, y las instancias se ejecutarán en el contexto de la (s) cadena (s) de host. (Esto es diferente, por ejemplo, del marco de plugin Jedi VCL, que instancia el plugin en el DLL o BPL y devuelve la instancia al host.)

Las primeras pruebas no mostraron problemas hasta el momento. Sin embargo, ¿hay problemas ocultos con la gestión de memoria de los que debería tener conocimiento? Como uso Delphi 2009 para este proyecto, FastMM4 es el administrador de memoria predeterminado.

aquí un bosquejo del proyecto de plugin DLL:

library ExamplePlugin; 
uses 
    ... 
type 
    TPluginOne = class(TInterfacedObject, ...) 
    ... 
    end; 

function RegisterPlugin: TInterfacedClass; stdcall; 
begin 
    Result := TPluginOne; 
end; 

exports 
    RegisterPlugin; 

{ TPluginOne } 
// ... plugin class implementation 

begin 
end. 

Answer 1

No hay problemas con el administrador de memoria, porque FastMM funciona como un administrador de memoria compartida entre el EXE y el DLL. Pero realmente no me siento cómodo con el concepto de pasar objetos puros, o (peores) metaclases entre el DLL y el EXE. El problema es que TInterfacedObject desde el EXE no es lo mismo que TInterfacedObject desde el DLL! Claro, pueden parecer exactamente iguales, ¡pero no lo son! Y si alguna vez actualiza la versión de Delphi para el EXE o para cualquiera de los DLL, tendrá que reconstruir todo (perdiendo así cualquier ventaja que haya obtenido al implementar un marco de Plugin).

Una solución mucho más portátil sería devolver un "Interfaz de fábrica", algo a lo largo de las líneas de:

IFactoryInterface = interface 
[GUId-goes-here] 
    function MakeWhateverInterfaceYouNeed: IUnknownDerivate 
end; 

luego exportar una función con esta firma:

function RegisterPlugin: IFactoryInterface; 

Answer 2

Su código es incompleta, sino de lo que ha incluido hay una falla obvia.

Parece que está exportando una clase (TInterfacedClass) desde una DLL. Esto causará problemas cuando los clientes intenten consumir su clase con una versión diferente de Delphi. Lo que es más, los dejará indefensos si quieren escribir complementos en un idioma diferente.

Personalmente, elegiría una interfaz COM que permita a los autores de complementos crear complementos en cualquier idioma. Este es, de hecho, el mismo problema que COM fue inventado para resolver.

Si está contento de tener que usar el mismo compilador para complementos y aplicaciones de host, y prefiere exponer las clases a las interfaces COM, entonces debe asegurarse de que todas las desasignaciones se realicen con el mismo administrador de memoria como asignado la memoria. La forma más sencilla es usar ShareMem y entonces estarás a salvo.

ACTUALIZACIÓN

Cosmin señala en un comentario de otro defecto con la exportación de clases a través de límites de módulos. Básicamente es algo que no deberías hacer. COM fue diseñado para este propósito y aún debe ser la primera opción para usted. interfaces de Delphi que son COM compatible para que pueda obtener los mismos beneficios de la interoperabilidad binaria sin tener que crear servidores, registro de CLSID etc.

Creo que el plug-in debería tener este aspecto:

library ExamplePlugin; 

type 
    TPluginOne = class(TInterfacedObject, IPlugin) 
    [GUID] 
    public 
    constructor Create(const Host: THostApp); 
    end; 

function RegisterPlugin(const Host: IHostApp): IPlugin; stdcall; 
begin 
    Result := TPluginOne.Create(Host); 
end; 

exports 
    RegisterPlugin; 

begin 
end.