Thunk
Thunk es un término usado en la jerga del desarrollo de software que designa la llamada o invocación a un código que pertenece a otra plataforma o a otro Framework. En el paso de 16 a 32 bit por ejemplo, los sistemas operativos (OS/2, Windows NT etc.) podían resolver código de 16 bit a través de la transformación de los parámetros de llamadas y direcciones, de modo tal que fue posible seguir utilizando los programas de 16 bit.
En el desarrollo de software moderno, un thunk es la llamada del código nativo desde el código gestionado y viceversa (véase por ejemplo Java Native Access o .NET P/Invoke). Es decir, se trata de una plataforma de transición, en la que las convenciones y/o parámetros de invocación tienen que transformarse correspondientemente (Marshalling). El lenguaje de programación C++/CLI del .NET-Framework de Microsoft fue concebido especialmente para posibilitar tales thunks en ambas direcciones:
Invocación por «gestionada» a «no gestionada»
Sea dada una clase nativa en C++, por ejemplo un proyecto C++ o como parte integrante de un proyecto C++/CLI, que se utilizará más abajo en código gestionado:
public class CNativeClass { private: int m_i; public: void SetValue( int i ) { m_i = i; } }; La clase gestionada C++/CLI (que en esta forma puede ser directamente instanciada, por ejemplo, en C#), la cual utiliza la clase nativa mostrada anteriormente:
public ref class CManagedClass { public: CManagedClass() { System::Int32 i = 42; CNativeClass* pNativeClass = new CNativeClass(); pNativeClass->SetValue( i ); // Implementación del tipo de datos delete pNativeClass; } }; Invocación por «no gestionada» a «gestionada»
La clase gestionada C++/CLI :
public ref class CManagedClass { private: System::Int32 m_i; public: void SetValue( int i ) { m_i = i; // Implementación del tipo de datos } }; Las clases nativas C++ en un proyecto C++/CLI. Aquí se puede ver que también el camino inverso es posible, es decir, instanciar el código gestionado dentro de una clase no gestionada. La condición es, sin embargo, que se trate de un proyecto C++/CLI, de modo tal que el compilador comprenda la correspondiente sintaxis. El thunk ya aparece en la instrucción «gcnew», ya que aquí se invoca al constructor de la clase gestionada:
public class CNativeClass { public: void Foo() { int i = 42; CManagedClass^ pManagedClass = gcnew CManagedClass(); pManagedClass->SetValue( i ); } }; Aplicaciones
La programación funcional
A pesar de que la industria estandarizada del software, ha estado dominada en gran medida por la programación funcional con referencias de evaluación,[1] el Thunk posee una amplia comunidad que lo usa para aplicaciones de investigación en programación funcional para crear lenguajes de programación. Esta investigación produjo una serie de lenguajes de programación con Evaluaciones perezosas en el que las variantes dependían de estrategias de evaluación estándar. Los compiladores de idiomas, como el caso del Glasgow Haskell Compiler, han dependido en gran medida de los procesadores sencillos, con la característica añadida de que los procesadores salvan su resultado inicial de modo que así pueden evitar volver a calcularlo;[2] esto se conoce en inglés como memoization.
Interoperabilidad
Los Thunks han sido ampliamente utilizados para proporcionar interoperabilidad entre los módulos de software cuyas rutinas de programación no pueden comunicarse directamente entre sí, como en los siguientes casos.
- Los software de rutina que tienen diferentes convenciones de llamada o utilizan diferentes representaciones de datos.
- Los software con rutinas que se ejecutan en diferentes modos del procesador del CPU, o en diferentes espacios de dirección, o al menos uno se ejecuta en una Máquina virtual.
Un compilador (u otra herramienta) puede resolver este problema mediante la generación de un thunk que automatiza los pasos adicionales necesarios para llamar a la rutina de destino, ya que se ocupa de la transformación de datos, el copiarlos a otra ubicación, o cambia el modo de procesamiento. Un Thunk exitoso minimiza el trabajo extra que la persona debe ejecutar con muchas notificaciones, y solo debe ocuparse de una notificación regular en todo el proceso.
Gran parte de la literatura sobre los procesadores de interoperabilidad se refiere a diversas plataformas Wintel, incluyendo MS-DOS, OS/2,[3] Windows[4][5] y Microsoft .NET, para la transición del direccionamiento de memoria de 16 bits a 32 bits. A medida que los clientes han migrado desde una plataforma a otra, los procesadores han sido esenciales para apoyar el legado del software escrito de las plataformas más antiguas.
Véase también
Sistemas con Thunks
Conceptos Relacionados
Bibliografía
- Marcus Heege: Expert C++/CLI. Apress Verlag, Berkeley 2007, ISBN 978-1-59059-756-9, Capítulo 9, p. 203 y siguientes.
Referencias
- Scott, Michael (2009). Programming Language Pragmatics. p. 395.
- Marlow, Simon (2013). Parallel and Concurrent Programming in Haskell. p. 10.
- Calcote, John (May 1995), «Thunking: Using 16-Bit Libraries in OS/2 2.0», OS/2 Developer Magazine 7 (3).
- King, Adrian (1994), Inside Windows 95.
- Hazzah, Karen (1996), Writing Windows VxDs and Device Drivers.