12. DSO (Dynamic Symbol Object)

Vous connaissez peut-être les objets partagés (so = shared object) ou les dlls (dll=dynamic link library). Grossièrement on peut dire que DSO est né du principe des so/dll. Mais on parle de dso (Dynamic Symbol Object) pour les différencier des librairies dynamiques so/dll.

Pour comprendre le fonctionnement des dso, il faut savoir comment fonctionne le link et le chargement. En général, lorsqu’on utilise des librairies dynamiques, on les « link » avec le programme principal lors de la compilation. ld(1) s’occupe de cela sur Unix. ld(1) est connu en tant qu’éditeur de lien. Comme ld(1) est habituellement appelé par le compilateur lui-même gcc(1) de façon implicite, peut-être n’avez-vous jamais entendu parler de ld(1). Au mieux avez-vous vu des messages problème de « link » lors de la compilation. Cela signifie que ld(1) n’arrive pas à résoudre certains symboles que vous utilisez dans votre programme. En cours d’exécution, ld.so(8) charge les librairies dynamiques. S’il n’y arrive pas, vous verrez des messages d’erreur de chargement. En résumé, le « link » est fait lors de la compilation, et le chargement est fait lors de l’exécution. Si vous voulez en savoir plus, il vous suffit de lire les manuels ld(1) et ld.so(8).

Grâce à dso, le link et le chargement sont faits lors de l’exécution. Quel est l’intérêt d’un tel mécanisme ? La raison se résume en deux mots : architecture plugin. La seule chose que nous ayons à faire lors de la compilation est de définir les interfaces (« noms symboliques » et la manière les appeler, les paramètres à leur donner, donc) des modules qu’il devra être possible de charger. Le programme charge les modules pendant son exécution, et s’en sert au travers d’interfaces. Les modules dynamiquement « téléchargeables » peuvent ainsi être développés par des programmeurs indépendants. Vous pourrez ainsi rendre votre programme très flexible et extensible.

Voyons voir dso-sample.c. Vous pouvez y voir deux chaines : « libm.so » et « pow ». En réalité, pow(3) est une fonction basique et, en temps normal, n’a pas besoin d’être appelée sous forme de dso, mais c’est simplement pour l’exemple.

Au début, on appelle apr_dso_load() et on lui donne le nom de la librairie : « libm.so ».

/* extrait de dso-sample.c, vérif. des erreurs omise */
const char fname[] = "libm.so";
    apr_dso_handle_t *dso_h;
    apr_dso_load(&dso_h, fname, mp);

Comme vous pouvez l’imaginer, si vous voulez programmer en donnant la possibilité aux autres de faire des plugins pour votre programme, vous devez faire en sorte d’avroi un fichier dans lequel il y a tous les noms des plugins à télécharger. On a déjà quelque chose qui tourne plutôt bien : les modules apache. Leurs noms sont spécifiés, en général, dans le fichier de configuration principal : le fichier « httpd.conf ».

Lorsque apr_dso_load() renvoie une erreur, c’est, la plupart du temps, parce qu’il ne trouve pas le fichier de la librairie dynamique. Le chemin de recherche pour les librairies dépend du système d’exploitation. Sur GNU/Linux, il dépend de la variable d’environnement LD_LIBRARY_PATH. Sur MS-Windows, il dépend de la variable d’environnement PATH. Après avoir un résultat de retour de apr_dso_load() réussi, on peut appeler apr_dso_sym().

Voici le prototype :

/* extrait de apr_dso.h */
APR_DECLARE(apr_status_t) apr_dso_sym(
    apr_dso_handle_sym_t *ressym,
    apr_dso_handle_t *handle,
    const char *symname);

On peut récupérer un objet par son nom via apr_dso_sym(). Le premier argument est un argument résultat. Le second argument est un handle dso, qu’on a avec apr_dso_open() expliqué précédemment. Le troisième argument est le nom du symbole.

Le code suivant est un extrait de dso-sample.c. Le nom du symbole est « pow » et on récupère un pointeur de fontion en tant qu’objet. Comme on connait l’interface de pow(3), il nous suffit de définir la fonction en tant que type : pow_fn_t.

/* extrait de dso-sample.c, vérif. des erreurs omise */
typedef double (*pow_fn_t)(double x, double y);
pow_fn_t pow_fn;

/* récupérer la fonction pow(3) de libm.so */
apr_dso_sym(
    (apr_dso_handle_sym_t*)&pow_fn,
    dso_h, "pow");

/* appeler pow(3) */
printf("%d ^ %d = %f\n", 2, 2, pow_fn(2, 2));

Si votre programme a des plugins, vous devrez définir des noms symboliques ainsi que leurs interfaces. Par la suite, les développeurs devront s’appuyer sur ces déclarations. Enfin, on appelle apr_dso_unload() pour libérer le module. Cela diminue ainsi la consommation mémoire.