<-
Apache > Servidor HTTP > Documentaci�n > Versi�n 2.0

Soporte de Objetos Dinamicos Compartidos (DSO)

Idiomas disponibles:  en  |  es  |  fr  |  ja  |  ko 

El servidor HTTP Apache es un programa modular en el que el administrador puede elegir qu� funcionalidades se incluyen mediante la selecci�n de un conjunto de m�dulos. En primer lugar, los m�dulos pueden compilarse de manera est�tica en el binario httpd. De forma alternativa, los m�dulos tambi�n pueden compilarse como Objetos Dinamicos Compartidos (DSOs) que existen de forma independiente del archivo binario httpd. Los m�dulos que se deseen usar como objetos din�micos compartidos pueden compilarse al mismo tiempo que el servidor, o pueden compilarse en otro momento y ser a�adidos despu�s usando la Herramienta de Extensi�n de Apache (apxs).

Este documento describe c�mo usar los m�dulos en forma de objeto din�mico compartido (DSO) as� como los fundamentos te�ricos que hay detr�s para explicar su funcionamiento.

top

Implementaci�n

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.

top

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.

top

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.

top

Ventajas e Inconvenientes

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

DSO presenta los siguientes inconvenientes:

Idiomas disponibles:  en  |  es  |  fr  |  ja  |  ko