Par Marco Fioretti

WebAssembly, ou Wasm pour abréger, est un Format de logiciel exécutable optimisé pour le Web, conçu pour donner aux programmeurs la plus grande flexibilité possible. Les modules binaires Wasm peuvent être compilés une fois, puis exécutés en toute sécurité n’importe où, seuls ou intégrés dans d’autres applications. En pratique, Wasm a besoin d’au moins trois composants clés pour tenir cette promesse. Deux d’entre eux, déjà présentés dans cette série, sont les Interface système WebAssembly (WASI), et Types d’interfaces Wasm.

WASI donne aux modules Wasm des moyens standard et indépendants de la langue d’interagir avec n’importe quel environnement hôte dans lequel ils peuvent atterrir. Les types d’interface, au contraire, sont des définitions également standardisées, mais pour toutes sortes de variables logicielles. En les utilisant, les modules Wasm peuvent se transmettre des structures de données complexes sans risquer de les corrompre, même si elles ont été écrites par des programmeurs indépendants dans des langages sources très différents. L’autre pièce principale de ce puzzle s’appelle liaison de modules. C’est ce qui permet à des fichiers binaires distincts d’interagir directement – par exemple en utilisant les fonctions les uns des autres – comme s’ils étaient tous deux écrits sous forme de sections différentes du même code source, puis compilés ensemble.

Les avantages et les inconvénients de la liaison des modules Wasm

La première raison de lier les modules Wasm est celle qui est toujours valable dans tous les domaines de la programmation, c’est-à-dire la réutilisation. Si une bibliothèque de, disons, fonctions mathématiques ou réseau peut être écrite (et maintenue !) une fois, mais d’une manière qui permet à des milliers de programmeurs de l’utiliser avec peu ou pas d’effort, tout le monde y gagne.

L’autre raison est encore plus simple, mais particulièrement importante pour un format comme Wasm : la vitesse. Au moins dans un avenir prévisible, la plupart des modules Wasm seront téléchargés par un serveur distant, éventuellement sur une liaison mobile lente, pour être exécutés à la volée. Dans tous ces cas, chaque seconde supplémentaire consacrée au téléchargement et à la préparation du code peut faire la différence. Si une grande application Wasm est divisée en modules séparés et interconnectés, son hôte ne peut télécharger que ceux dont ses propres utilisateurs ont besoin, et uniquement lorsqu’ils réellement besoin d’eux. Pour réduire davantage les téléchargements, les modules fréquemment demandés peuvent même être mis en cache localement.

Bien sûr, il peut y avoir trop de bonnes choses. L’utilisation de nombreux modules, en particulier de nombreuses sources indépendantes, accélère le développement logiciel, mais peut rendre son maintenance plus complexe à long terme. En même temps, sur tout réseau stable, télécharger et lier plusieurs modules prend, presque par définition, plus de temps que d’obtenir simplement un blob de code qui fait exactement la même chose. De plus, les appels de fonction entre les modules Wasm liés « peut être plus lent que les appels de fonction dans un module ». Dans l’ensemble, tous ces facteurs peuvent entraîner une baisse des performances réelles de quelques points de pourcentage. Dans de nombreux cas, ce sera un prix très raisonnable à payer.

La façon Wasm de lier des modules

Les modules Wasm développés indépendamment peuvent toujours être « liés » de la même manière qu’ils sont utilisés pour d’innombrables applications logicielles, c’est-à-dire au moment de la compilation. Cela produit un fichier exécutable qui possède toutes les fonctionnalités souhaitées et est prêt à être exécuté dans n’importe quelle machine virtuelle compatible Wasm/WASI. En plus de dépendre des langues et de la chaîne d’outils spécifiques utilisées pour générer chaque fichier exécutable, cette statique l’enchaînement est presque à l’opposé du résultat souhaité : un « écosystème portable, indépendant de l’hôte et de la langue » de modules WebAssembly composables selon les besoins après, pas avant de les avoir téléchargés, et peu importe d’où ils viennent.

Un premier, si petit pas dans cette direction, consiste à utiliser les Types d’interfaces Wasm: ils peuvent, en effet, faire échanger différents modules Wasm copies de leurs structures de données, sans pour autant les partager mais comme s’ils faisaient partie du même programme. Cette forme limitée de coopération entre les modules est appelée « liaison sans partage ».

Le type de lien qui est vraiment cohérent avec la philosophie de base de Wasm, cependant, est celui qui se produit uniquement quand et où cela est vraiment nécessaire, ne gaspille pas de ressources et, surtout, n’impose pas de contraintes inutiles aux fournisseurs de Wasm. modules. La liaison, c’est-à-dire, devrait se produire sur l’hôte qui en a réellement besoin, mais sans pour autant nécessitant aucune préparation pour les modules qui sont liés, ou toute personnalisation spécifique à l’application pour les programmeurs qui les ont écrits.

Cela signifie que les binaires Wasm doivent utiliser une technique de virtualisation pour déclarer et importer les autres modules (ou des parties de ceux-ci) qu’ils souhaitent lier. Ce mécanisme, appelé « virtualisation en temps de lien », permettrait à terme ce que l’on appelle le « Shared-Everything Dynamic Linking », dans lequel tous les modules liés pourraient partager directement leur mémoire et leurs tables de données, sans duplications. Les détails sanglants de bas niveau de cette approche sont décrits dans la section correspondante du document officiel Explication pour la liaison des modules Wasm. Ici, nous ne mentionnons que deux des propriétés générales, ou contraintes, que chaque solution de liaison «pure-Wasm» devrait inclure.

Le premier est le « Principe de moindre autorité », par lequel chaque module Wasm doit toujours exposer à son hôte, ou lui demander, uniquement le plus petit sous-ensemble possible de capacités dont il a besoin pour faire son travail. L’autre est, pour le dire simplement, que les modules de liaison ne doivent pas faire Collecte des ordures ménagères à Wasm plus compliqué qu’il ne l’est déjà.

En pratique : Emscripten, API JavaScript et WAPM

Les outils les plus élémentaires pour créer et utiliser à partir de zéro des modules Wasm liés sont des fonctions comme dlopen() en C ou C++ ou, en JavaScript, les API WebAssembly équivalentes. Avec les instructions appropriées, le Chaîne d’outils Emscripten peut ajouter, à la logique de collage qui permet aux machines virtuelles JavaScript de charger et d’exécuter du code Wasm, un bibliothèques dynamiques tableau qui répertorie tous les modules qui doivent être téléchargés puis liés. Pour étudier ou utiliser des modules complets pouvant être liés à la place, consultez le registre officiel du Gestionnaire de packages WebAssembly (WAPM), un outil open source dont le but est justement de faciliter la publication et l’installation de tels modules.

La poste Comment et pourquoi lier des modules WebAssembly est apparu en premier sur Fondation Linux – Formation.