 |
 |
 |
Extensión y empotrado del intérprete de Python |  |
 |
|
|
|
|
Extensión y empotrado del intérprete de Python | |
|
|
Unix y Windows parten de paradigmas completamente diferentes para la carga de código en tiempo de ejecución. Antes de intentar construir un módulo con carga dinámica, se debe comprender cómo funciona el sistema final del usuario.
En Unix, un fichero objeto compartido (shared object, .so) contiene código que será utilizado por el programa junto con los nombres de las funciones y datos que espera encontrar en el programa. Cuando el fichero se une al programa, se cambian todas las referencias a dichas funciones y datos para que apunten a sus direcciones de memoria reales en el programa. A grandes rasgos, se realiza una operación de enlace.
En Windows, un fichero de biblioteca de enlace dinámico, (dynamic-link library, .dll) no tiene referencias pendientes. En lugar de ello, todo acceso a funciones y datos pasa por una tabla de consulta. Por ello, no hay que arreglar el código de la DLL para que haga referencia a la memoria del programa. El programa ya utiliza la tabla de búsquedas, lo que cambia en tiempo de ejecución es la tabla de búsquedas para apuntar a las funciones y datos finales.
En Unix, sólo hay un tipo de fichero de biblioteca (.a) que contiene código de varios ficheros objeto (.o). En el paso de enlace para crear un fichero objeto compartido (.so), el enlazador puede encontrarse que desconoce dónde se define un identificador. El enlazador lo buscará en los ficheros objeto y en las bibliotecas. Si lo encuentra, incluirá todo el código del fichero objeto.
En Windows, existen dos tipos de biblioteca, una biblioteca estática y una biblioteca de importación (ambas llamadas .lib). Una biblioteca estática es como un fichero .a de Unix: contiene código que se incluirá si es necesario. Una biblioteca de importación se usas sólo para asegurar al enlazador que un identificador concreto es legal y estará presente en el programa cuando se cargue la DLL. Por ello, el enlazador utiliza la información de la biblioteca de importación para construir la tabla de consulta para usar los identificadores no incluidos en la DLL. Cuando se enlaza una aplicación o DLL, puede generarse una biblioteca de importación, que tendrá que usarse para futuras DLLs que dependan de los símbolos de la aplicación o DLL.
Supóngase que se están construyendo dos módulos de carga dinámica, B y C, que han de compartir otro bloque de código A. En Unix, no se pasaría A.a al enlazador para B.so y C.so; eso causaría que se incluyera dos veces y tanto B como C tendrían su propio ejemplar. En Windows, al construir A.dll se construiría A.lib. Sí se pasaría A.lib al enlazador tanto en B como en C. A.lib no contiene código, sólo información que se usará en tiempo de ejecución para acceder al código de A.
En Windows, usar una biblioteca de importación es análogo a usar "import spam"; proporciona acceso a los nombres de spam, pero no genera una copia aparte. En Unix, enlazar con una biblioteca es más como "from spam import *"; sí genera una copia aparte3.1.
|
|
|
Extensión y empotrado del intérprete de Python | |
|
|