Soporte de Objetos Dinamicos Compartidos (DSO)

Implementaci�n

M�dulos Relacionados	Directivas Relacionadas
mod_so	LoadModule

Cargar m�dulos de Apache individualmente como objetos din�micos compartidos (DSO) es posible gracias a un m�dulo llamado mod_so que debe compilarse est�ticamente en el n�cleo (kernel) de Apache. Es el �nico m�dulo junto con el m�dulo core que no se puede usar como objeto din�mico compartido. Pr�cticamente todos los dem�s m�dulos distribuidos con Apache se pueden usar como objetos din�micos compartidos individualmente siempre y cuando se haya activado la posibilidad de usarlos con la opci�n de configure --enable-module=shared tal y como se explic� en la documentaci�n de instalaci�n. Una vez que haya compilado un m�dulo como objeto din�mico compartido y le haya puesto un nombre del tipo mod_foo.so, puede cargarlo al iniciar o reiniciar el servidor usando el comando LoadModule de mod_so en el fichero httpd.conf.

Para simplificar la creaci�n de objetos din�micos compartidos para Apache (especialmente m�dulos de terceras partes) est� disponible un nuevo programa de soporte llamado apxs (APache eXtenSion). Puede usar este programa para crear m�dulos como objetos din�micos compartidos sin tener que crearlos al mismo tiempo que compila su servidor Apache. La idea es simple: cuando se instala Apache el procedimiento make install de configure @@@ installs the Apache C header files and puts the platform-dependent compiler and linker flags for building DSO files into the apxs program / instala los ficheros de cabecera de C de Apache y especifica las opciones de compilaci�n y enlace dependientes de la plataforma para generar objetos din�micos compartidos con apxs. De esta manera el usuario puede usar apxs para compilar el c�digo fuente de m�dulos de Apache de manera independiente y sin tener que preocuparse por las opciones de compilaci�n y enlace dependientes de la plataforma que soportan objetos din�micos compartidos.

Resumen de uso

Para que se haga una idea de lo que permite el soporte de objetos din�micos compartidos en Apache 2.0, aqu� tiene un resumen breve pero conciso:

1. Construir e instalar un m�dulo incluido en la distribuci�n de Apache, digamos mod_foo.c, como un objeto din�mico compartido de nombre mod_foo.so:

   $ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install

2. Construir e instalar un m�dulo de Apache de una tercera parte, digamos mod_foo.c, como un objeto din�mico compartido de nombre mod_foo.so:

   $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install

3. Configurar Apache para poder instalar despu�s objetos din�micos compartidos:

   $ ./configure --enable-so
$ make install

4. Construir e instalar un m�dulo de Apache de una tercera parte, digamos mod_foo.c, como un objeto din�mico compartido de nombre mod_foo.so fuera de la estructura de directorios de Apache usando apxs:

   $ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la

En todos los casos, una vez que se compila el objeto din�mico compartido, debe usar una directiva LoadModule en httpd.conf para activar dicho m�dulo.

Fundamentos teor�ricos detr�s de los objetos din�micos compartidos

En las versiones modernas de Unix, existe un mecanismo especialmente �til normalmente llamado enlazado/carga de Objetos Din�micos Compartidos (DSO). Este mecanismo ofrece una forma de construir trozos de c�digo de programa en un formato especial para cargarlo en tiempo de ejecuci�n en el espacio de direcciones de memoria de un programa ejecutable.

Esta carga puede hacerse de dos maneras: autom�ticamente con un programa de sistema llamado ld.so al inicio de un programa ejecutable o manualmente desde dentro del programa en ejecuci�n con una interfaz program�tica del sistema al cargador de Unix mediante llamadas al sistema dlopen()/dlsym().

Si se usa el primer m�todo, los objetos din�micos compartidos se llaman normalmente librer�as compartidas � librer�as DSO y se nombran como libfoo.so o libfoo.so.1.2. Residen en un directorio de sistema (normalmente /usr/lib) y el enlace con el programa ejecutable se establece al construir la librer�a especificando la opci�n-lfoo al comando de enlace. Esto incluye las referencias literales a las librer�as en el programa ejecutable de manera que cuando se inicie, el cargador de Unix ser� capaz de localizar libfoo.so en /usr/lib, en rutas referenciadas literalmente mediante opciones del linker como -R o en rutas configuradas mediante la variable de entorno LD_LIBRARY_PATH. Entonces se resuelven los s�mbolos (todav�a no resueltos) en el programa ejecutable que est�n presentes en el objeto din�mico compartido.

Los s�mbolos en el programa ejecutable no est�n referenciados normalmente en el objeto din�mico compartido (porque son librer�as reusables de prop�sito general) y por tanto, no se producen m�s resoluciones. El programa ejecutable no tiene que hacer nada por s� mismo para usar los s�mbolos del objeto din�mico compartido porque todo el trabajo de resoluci�n lo hace @@@ Unix loader / el cargador de Unix @@@. (De hecho, el c�digo para invocar ld.so es parte del c�digo que se ejecuta al iniciar, y que hay en cualquier programa ejecutable que haya sido construido de forma no est�tica). La ventaja de cargar din�micamente el c�digo de las librer�as comunes es obvia: el c�digo de las librer�as necesita ser almacenado solamente una vez, en una librer�a de sistema como libc.so, ahorrando as� espacio en disco.

Por otro lado, los objetos din�micos compartidos tambi�n suelen llamarse objetos compatidos o ficheros DSO y se les puede nombrar con cualquier extensi�n (aunque su nombre can�nico es foo.so). Estos archivos normalmente permanecen dentro de un directorio espec�fico del programa y no se establecen enlaces autom�ticamente con los programas ejecutables con los que se usan. En lugar de esto, el programa ejecutable carga manualmente el objeto din�mico compartido en tiempo de ejecuci�n en su espacio de direcciones de memoria con dlopen(). En ese momento no se resuelven los s�mbolos del objeto din�mico compartido para el programa ejecutable. En lugar de esto, el cargador de Unix resuelve autom�ticamente los s�mbolos (a�n no resueltos en el objeto din�mico compartido del conjunto de s�mbolos exportados por el programa ejecutable y de las librer�as DSO que tenga ya cargadas (especialmente todos los s�mbolos de la omnipresente libc.so). De esta manera el objeto din�mico compartido puede conocer el conjunto de s�mbolos del programa ejecutable como si hubiera sido enlazado est�ticamente en un primer momento.

Finalmente, para beneficiarse de la API de las DSOs, el programa ejecutable tiene que resolver los s�mbolos particulares de la DSO con dlsym() para ser usado m�s tarde dentro de tablas de direccionamiento (dispatch tables) etc. En otras palabras: El programa ejecutable tiene que resolver manualmente cada uno de los s�mbolos que necesita para poder usarlo despu�s. La ventaja de ese mecanismo es que las partes opcionales del programa no necesitan ser cargadas (y por tanto no consumen memoria) hasta que se necesitan por el programa en cuesti�n. Cuando es necesario, estas partes del programa pueden cargarse din�micamente para expandir las funcionalidades b�sicas del programa.

Aunque este mecanismo DSO parece muy claro, hay al menos un paso de cierta dificultad: la resoluci�n de los s�mbolos que usa el programa ejecutable por la DSO cuando se usa una DSO para extender la funcionalidad de una programa (segundo caso). Por qu�? Porque la resoluci�n inversa de s�mbolos de DSOs del conjunto de s�mbolos del programa ejecutable se hace en contra del dise�o de la librer�a (donde la librer�a no tiene conocimiento sobre los programas que la usan) y tampoco est� disponible en todas las plataformas no estandarizadas. En la pr�ctica los s�mbolos globales del programa ejecutable est�n disponibles para su uso en una DSO. El mayor problema que hay que resolver cuando se usan DSOs para extender un programa en tiempo de ejecuci�n es encontrar un modo de forzar al enlazador a exportar todos los s�mbolos globales.

El enfoque de las librer�as compartidas es bastante t�pico, porque es para lo que se dise�o el mecanismo DSO, por tanto se usa para casi todos los tipos de librer�as que incluye el sistema operativo. Por otro lado, no muchos programas usan objetos compartidos para expandir sus funcionalidades.

En 1998, hab�a solamente unos pocos programas disponibles que usaban el mecanismo DSO para extender su funcionalidad en tiempo de ejecucion: Perl 5 (por medio de su mecanismo XS y el m�dulo DynaLoader), Netscape Server, etc. A partir de la version 1.3, Apache se uni� a este grupo, Apache usa desde entonces una concepci�n modular para extender su funcionalidad e internamente usa un enfoque de tablas de direccionamiento (dispatch-list-based) para enlazar m�dulos externos con las funcionalidades propias del servidor. De esta manera, Apache puede usar el mecanismo DSO para cargar sus m�dulos en tiempo de ejecuci�n.

Ventajas e Inconvenientes

Las caracter�sticas de las librer�as din�micas compartidas arriba explicadas tienen las siguientes ventajas:

• El servidor es mucho m�s flexible en tiempo de ejecuci�n porque pueden a�adirse m�dulos mediante comandos de configuraci�n LoadModule en httpd.conf en lugar de tener que hacerlo con las opciones de configure al compilar. Por ejemplo, de esta manera uno puede ejecutar diferentes instancias del servidor (est�ndar & SSL, m�nima & super potente [mod_perl, PHP3], etc.) con una �nica instalaci�n de Apache.
• El servidor puede ser extendido f�cilmente con m�dulos de terceras partes despu�s de la instalaci�n. Esto es un gran beneficio al menos para los mantenedores de paquetes de distribuciones, que pueden crear un paquete b�sico de Apache y paquetes adicionales que contengan extensiones tales como PHP3, mod_perl, mod_fastcgi, etc.
• Facilita la labor de hacer prototipos de m�dulos de Apache porque con el d�o DSO/apxs se puede trabajar fuera de la estructura de directorios de Apache y �nicamente es necesario el comando apxs -i seguido del comando apachectl restart para probar la nueva versi�n del m�dulo que se est� desarrollando.

DSO presenta los siguientes inconvenientes:

• El mecanismo DSO no puede ser usado en todas las plataformas porque no todos los sistemas operativos soportan la carga din�mica de c�digo en el espacio de direcciones de memoria de un programa.
• El servidor es aproximadamente un 20% m�s lento inici�ndose por la sobrecarga que implica la resoluci�n de s�mbolos por parte del cargador de Unix.
• El servidor es aproximadamente un 5% m�s lento ejecut�ndose en algunas plataformas porque el c�digo posicionado independientemente (PIC) necesita algunas veces procesos bastante complicados para calcular direcciones relativas que no son en principio tan r�pidos como los que se usan para calcular direcciones absolutas.
• Como los m�dulos DSO no pueden enlazarse a otras librer�as basadas en DSO (ld -lfoo) en todas las plataformas (por ejemplo en las plataformas basadas en a.out normalmente no puede ser usada esta funcionalidad, mientras que s� puede ser usada en las plataformas basadas en ELF) no se puede usar el mecanismo DSO para todos los tipos de m�dulos. En otras palabras, los m�dulos compilados como ficheros DSO solamente pueden usar s�mbolos del n�cleo (kernel) de Apache, los de las librer�as de C (libc) y de todas las demas librer�as din�micas o est�ticas usadas por el n�cleo de Apache, o de archivos de librer�as est�ticas (libfoo.a) que contengan c�digo independiente de su posici�n. Las �nicas posibilidades para usar otro c�digo es asegurarse de que el n�cleo de Apache contiene una referencia a �l o cargar el c�digo por medio de dlopen().